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CHAPTER 1 
INTRODUCTION 

Welcome to Intel's new iAPX 432 family of components. The 

432 product line was designed to solve the [existing; 
growing?] industrial problem of software development. 
Today's state-of-the-art technology has produced large-scale 
microprocessors capable of handling tremendous hardware 
tasks, but has failed to relieve the ever-growing needs of 
software design. Complex devices, conceptually designed to 
control this problem have in the end only added more weight 
to the burden. 

WHAT IS THE PROBLEM? 

Today's system applications have evolved into highly complex 
configurations. Retail business systems, telephone switching 
systems, laboratory and industrial control systems, commun- 
ication systems, word processors, and many other large-scale 
systems have forced the industry to consider alternative 



methods of handling the extensive requirements of multiple 
programs, multiple users, and multiple processors. The 
demands of existing high-level languages, operating system 
software, and the increased number of peripheral controllers 
and memory options have produced overwhelming problems for 
the system designer. 

To further compound the problem, tommorrow^s applications 
will increase system complexity by requiring fault-tolerant 
computing, transparent multiprocessing, distributed opera- 
tion, networking, and multiple families of programming 
languages. These system requirements are beyond the scope of 
today^s mini- and mainframe computers. This Component Dser^s 
Guide presents a hardware discussion of the two components, 
the 43201 and 43202, that combine to form the General Data 
Processor (GDP), and the 43203 Interface Processor (IP). 
Also included in this book are instructions concerning the 
hardware implementation of the iAPX 432 system concepts. 
References to additional source documents are given as 
needed. 

WHAT IS THE SOLUTION? 

As you become familiar with the iAPX 432 family members, you 
will discover an innovative approach to the software 
development problem. It is not enough to say the 432 family 
processors have an enhanced architecture with the integra- 
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tion of over 100,000 silicon gates into 64-pin packages, 
nor is it enough to promise an increased throughput. What 
must be understood is that all phases of hardware and 
software design will be oriented toward safe and efficient 
control of information with favorable results in develop- 
ment costs. 

The solution to complex and growing software demands is the 
development of the object-oriented machine. Such a machine 
can provide the important qualities of abstraction and 
decomposition. Abstraction is one of the inherent qualities 
of the iAPX432 family, which hides the irrelevant detail of 
predefined high-level languages, e.g., different number and 
data types. Decomposition is the quality of breaking up 
complex problems into manageable units and allows for 
modular programming. The iAPX 432 hardware provides an 
architectural structure that defines access limitations to 
prevent the damage of any established data base. The 
software designer need only be concerned with the construc- 
tion of individual, easy-to-understand program modules that 
are more manageable and capable of working together as a 
system unit. Refer to Chapter 2 for a discussion of 432 
Architecture and its importance to the hardware designer. 

HOW IS IT DONE? 

A basic iAPX 432 system consists of one or more Intel 
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general data processors (GDP's) , one or more interface 
processors (IP's) , several independant I/O systems, and a 
common memory " system. Each external I/O system may consist 
of several I/O devices and microprocessors that may be 
capable of providing their own complex arbitration schemes, 
memory interleaving, and dynamic memory configuration. These 
external processors view memory as a single and continuous 
byte-addressable sequence, and are not aware of any system 
interconnection (although that capability does exist) . 
Figure 1-1 illustrates a basic 432 system. 

Figure 1-1 432 System Block Diagram 

Program.s executing in iAPX 432 processors view the memory 
and the interconnect address spaces quite differently from 
their attached processors. Programs are hardware-defined as 
processes, which are controlled by access descriptors; i.e., 
each process is limited to specific objects that may only be 
accessed if predefined conditions have been met. After 
verifying access rights, the hardware automatically computes 
physical addresses as they are required. The external 
processors define processes; the interface processor 
provides access to general data processors and memory 
resources to run those processes. 
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Processor management methodology becomes more important as 
more subsystems are added. In the iAPX 432 system, processes 
are scheduled to be executed according to policies, imple- 
mented in software, that determine how processes are to 
share processors. As each process becomes available, i.e., 
reaches the head of its queue, it is dispatched to the next 
available processor that can execute the process. Converse- 
ly, an idle processer will wait at a dispatching port for a 
process to appear. Therefore, systems may becom.e as complex 
as the mind can imagine. Software Engineers are now pleased 
to discover that the need to develop or redesign new 
software to handle the complexity of increasing system 
requirements does not exist! Hardware engineers are pleased 
to save valuable design effort in increasing the hardware 
capabilities by simply plugging additional GDP or IP units 
into their printed circuit boards. Chapters 5 and 6 provide 
a detailed discussion of the GDP and the IP and their 
respective roles in implementing these concepts. 

Figure 1-2 represents an iAPX 432 system model complete with 
three GDP processors (43201 and 43202) , three IP processors 
(43203) , and three I/O subsystems. If the external 
processors were identical, it would be conceivable to use 
only one IP and several GDP^s. The figure illustrates the 
ease with which information is allocated to available 
processors. Also shown is the independance of each subsystem 
as separate tasks are defined without the need for under- 
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standing tasks for other subsystems. Refer to Chapter 4 
for an actual 432 system configuration. 

OBJECT-ORIENTED MACHINE 

An object is a data structure that contains information in 
an organized manner. An object-oriented machine, such as the 
iAPX 432, is a device that handles data in terms of objects 
rather than the specific elements within the object. Certain 
primitive data types {Reals, Integers, Ordinals, etc.) each 
have a specific structure that may vary from one type to the 
next. A given binary number might represent a different 
meaning to each of these data types. In the iAPX 432 
architecture, these data structures may be found in a 
contiguous set of memory locations or possibly a combination 
of several segments. 

A 432 object not only contains organized information but 
also a basic set of operations defined to directly manipu- 
late the data structure. The 432 hardware inherently ensures 
manipulation of the data structure by these specific 
operations only. In this manner, violations to the data 
structure are prevented. Also, each object can be referenced 
as one thing; i.e., there is no need to address any of the 
parts. Therefore, each object has a label to identify it 
from among the various types. 



6 



Notice that objects are manipulated not only by the 
hardware. Some objects are manipulated by a combination of 
hardware and software, and some only by software. Frequently 
used operations have been placed in the 432 structure 
(hardware implemented) while less frequent operations have 
been left to the software. Refer to Chapter 2 for a discus- 
sion of the following objects: Processor objects. Process 
objects. Context objects. Instruction objects, and data 
objects. The coordination of these objects represents the 
completed picture of the 432 system. 

A FINAL NOTE 

The Intel iAPX 432 family of components has been designed 
specifically to provide a solution to the growing software 
needs of the 80's. The 432 system should be viewed as a 
time-saving system, a cost-saving system, and a system to 
solve design development problems. Welcome to the Object- 
Oriented world of Intel's iAPX 432 family. 
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CHAPTER 2 



INTRODUCTION TO iAPX 432 ARCHITECTURE 

The purpose of this chapter is to familiarize the iAPX 432 
hardware designer with the basic object-oriented concepts 
provided by the 432 system. A solid understanding of the 
following concepts is essential to the construction of 432 
systems (Refer to the iAPX 432 General Data Processor 
Architectural manual. Order no. 171860, and the iAPX 432 
Interface Processor Architectural manual. Order No. 171862, 
for more detailed information on these concepts) . 

The iAPX 432 system is an object-oriented, capability-based 
architecture that supports software-transparent multiproces- 
sing and adaptive virtual memory. By including operating- 
system and high-level language functions in hardware, it 
provides mainframe functionality and performance in a VLSI 
microcomputer form factor. I/O processing is fully indepen- 
dent and decentralized, allowing other iAPX processors 
(e.g., 86, 186) to perform I/O as attached processors. The 
IEEE floating point standard is fully supported in hardware. 

The iAPX 432 combines VLSI technology with an architectural 
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and software design methodology to produce a new computer 
architecture that will significantly reduce the cost of 
large-scale software systems and enhance their reliability 
and security. 

Several key concepts are fundamental to an understanding of 
the iAPX 432 architecture. They are: 

Objects — data structures having known types that can be 
either system- or user-defined; moreover, objects are 
acted upon by a restricted set of operations, which can 
be individual machine instructions, software package, 
or hidden hardware functions. In the 432, objects are 
represented by segments, subsets of segments called 
refinements, or arbitrarily complex networks of 
segments and/or refinements. 

Access descriptors — sometimes called "object references" 
or "capabilities," these are how objects refer to one 
another. Each object confers upon its holder access to 
an object, along with certain rights associated with 
the object, for instance, read/write or send/receive. 

Segments — segments form the basis for the physical 
representation of objects. Each segment is a contigu- 
ous block (that is, no gaps) of address space, up to 
64K (65,536) bytes long. Each segment has a hardware- 
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recognized base type, which must be either data segment 
or access segm.ent. 

Data Segments — data segments have no inherent structure, 
but are hardware-recognized. They are variously used 
to hold instructions and scalar data items, but not 
object references. 

Access Segments — each access segment is a hardware- 
recognized array of object references, protected by the 
hardware to ensure that inadvertent or malicious 
alteration of access rights or addressing information 
does not occur. 

System Management Objects — in addition to a base type (data 
segment or access segment) , each segment is assigned a 
system type so that objects can be built to represent 
processors, processes, and storage resources. The 
hardware-recognized typing of these objects, together 
with a restricted set of operations defined on each 
type, facilitates efficient system management as 
processor management, process management, and storage 
management. 

Program Environment Objects — by building "packages" or 
modules of arbitrarily complex objects, a protected 
program environm.ent is established wherein access to 
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instructions, scalar data items, and objects can not 
only be controlled, but also hidden. Programming 
abstractions such as "subroutine activation records" 
and "static access environment" are realized in the 
hardware as contexts and domains, respectively. 

User-defined Objects — also called "extended-type" objects, 
these are objects whose structure and behavior are 
defined by the user. This extends the concept of 
hardware typing to include arbitrary objects (and 
networks of objects) that can only be acted on by a 
restricted set of operations, which may also be defined 
by the user. 

Type Management Objects — in order to manage the arbitrary 
user-defined types, the objects that are instances of 
those types, and the operations that act upon them, the 
432 architecture provides a hardware-recognized type 
definition object that can be selectively made avail- 
able to other users, even though its inner workings are 
hidden from them. 

Object Locking — objects can be locked by either hardware 
or software to ensure object integrity in a multiple 
processor environment. 

OBJECTS 
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Operations Defined on Data Types 

The concept of an object grows out of the natural concept of 
different data types having different operations that act 
upon them. Schematically, we depict the situation as shown 
in Figure 2.1. 

Figure 2-1. Operations Defined on a Data Type 

Operations Defined on CHARACTER and INTEGER types 

Data types such as CHARACTER and INTEGER are familiar 
examples of data types. The data items ^A^ and 65 are 
instances of these respective types, which are conceptually 
different, even though they have the same internal represen- 
tation, assuming ^A' is represented in ASCII and 65 is 
represented as a pure binary number in a byte. 

These data types may have different operations defined on 
them by: 

o Machine instructions (such as an editing instruction 
for characters, or an arithmetic instruction for 
integers) , 



12 



OPERATION 1: 



OPERATION 2 



OPERATIONS' 




^^^yj^ E "Q^ O PERATI ONS DEFIN ED ON A D ATA TYPE , 



o Hidden hardware functions (such as a table look-up for 
a character, or forming the 2's complement of an 
integer) , 

o Software-implemented functions (such as character 
substring functions, or exponentiation of integers) . 

Schematically, we can depict this situation as shown in 
Figure 2-2. 

Figure 2-2. Some Operations Defined on CHARACTER and 
INTEGER Types. 

Characters and integers are not objects, but looking at them 
this way may help to understand the rationale of objects. 
Before CHARACTER and INTEGER data types were developed, they 
existed as abstractions. Programmers coding in octal or 
binary coded the chartacter ^A^ the same as if they were 
coding the integer 65, and the discipline of choosing the 
appropriate operations (instructions or subroutines) for the 
data types they had in mind were left to them. 

Programming languages and their translators (assemblers, 
compilers, and interpreters) introduced formalism.s of 
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subroutines, functions, and procedures into the "art" of 
programming code: by enforcing declarations of these 
formerly abstract concepts in programs, language translators 
could at least ensure that, for instance, a function call 
was being used as a function call. (An interesting counter- 
example of this occurred in FORTRAN, in which the statement: 

A = F{X) 

could be the assignment to A of either: 

the value of the function F evaluated using X as an argu- 
ment, or - 

the Xth element of the array F (depending on the declaration 
of F) . 

Software Data Types and Associated Operations 

As code abstractions (procedures, functions, and subrou- 
tines) demonstrated their merit in enforcing discipline in 
programming, data abstractions became realized as arrays, 
vectors, records, and other formal structures. Each essen- 
tially different kind of data structure was realized as a 
data type, and sets of operations were introduced to act 
upon only certain data types. 

For instance, the data type MATRIX was formalized in certain 
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languages, and the operations DETERMINANT and INVERT, 
usually implemented in software, could be performed only on 
a data structure of type MATRIX. If the type did not match 
the operation, the program would not compile properly. 

Compile-time checking ensured that execution time need not 
be wasted on large programs that would not run properly 
because a data type did not match the operation applied to 
it. 

Hardware-Recognized Data Structures and Associated Opera- 
tions 

The software concepts of typed data structures and the 
operations that can be applied to them are realized in the 
machine architecture of the iAPX 432. In doing so, the 432 
raises the level of the instruction interface from the 
traditional data computational types of bytes, double bytes, 
words, etc., to objects. 

Just as languages defined operations on primitive data 
types, the architecture of the 432 (and any language capable 
of embracing this architecture) defines operations on 
objects, which are instances of typed data structures. Thus, 
a machine instruction on the 432 typically specifies as its 
operands objects that represent: 
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o Processors in a multiprocessor environment 

o Processes (tasks) in a concurrent environment 

o Dispatching ports that bind processes to processors 

o Interprocess messages sent from one process to 
another, and synchronized using communication ports 

o Domains (also called type managers) as the static 

access environments of programs 

o Contexts (subprograms) 

And many more. These objects are all system objects; they 
are instances of system types, that is, types built into the 
system. 

Objects as high level, strongly typed operands 

Intuitively, a system object is a high level operand that 
raises the level of the instruction interface. "High-level" 
in this sense means that the operand, rather than simply 
being a byte or word of data, is an organized data structure 
in memory that is recognized by the hardware as being an 
instance of a type that can be m.anipulated only by a select 
class of operations. 
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Traditional computer systems implement the abstractions of 
access environment control, task management, process status, 
interprocess communication, etc. using a combination of 
software structures defined by operating systems, utilities, 
and compilers, and associated supervisor calls. 

The 432 implements these concepts as machine-inherent data 
structures referenced by instructions as strongly typed 
operands that are validity-checked at run time: 

o Each has a type (base and system) , and 

o Each can be used as an operand only as intended, i.e., 

only with a well defined subset of the operator 
(instruction) set. 

Many 432 system objects are highly organized "control 
blocks" reminiscent of operating task control, message 
queueing, fault handling, and other mechanisms. These 
"control block" system object operands do not in and of 
themselves enforce operating system policy, but rather 
provide the basic mechanisms from which virtually any 
operating system can be designed and built. These mechanisms 
provide functionality needed to design and build clean, fast 
running software. Indeed, for large, high availability 
systems, the software development cycle can be shortened 
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using the 432, 
Extended types 

The 432 architecture allows users to define arbitrary data 
structures as objects, and to define the restricted set of 
operations that are allowed to act on these objects. These 
user-defined object types are called extended types, since 
they extend the set of recognized object types and the 
operations allowed by each type. 

Exaiaple of a 432 object and its associated operations 

The processor object represents a unit of processing power 
in the system and as such is an abstraction of the physical 
processing unit, reflecting its various states (running, 
queued, assigned, etc.). Processor objects in a given system 
are in one-to-one correspondence with physical processors in 
that system. 

A processor object thus provides a means of assigning the 
processor it represents to a particular process set (work 
stream) , and also provides a means of communicating with 
(sending messages to) a processor. 

Operations 
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Figure 2-3 indicates a processor object and the operations 
that act apon it. 

Figure 2-3 Operations defined on a procesor object. 
Access descriptors — "handles" for objects 

When several users require access to the same object, at 
least two problems can arise: 

o Need-to-Know Rights. In a multi-user environment, not 
all users need to have the same rights to an object; 
for instance, one user may require only "read" rights 
to sensitive data, whereas another may require both 
"read" and "write" rights to that data structure 
(object) ; a mechanism is needed whereby different 
rights can be conferred on different instances of 
procedures. The solution to this problem is discussed 
below. 

o Exclusive Access. In a multiprocessor environment, 
one user of a data structure (object) may require 
exclusive access to that object for a particular 
operation, to ensure that no other processor alters 
the object while the operation proceeds. The solution 



19 



SEND to PROCESSOR: 



BROAD CAST TO P RO CESS 0 RSI 



READ PROCESSOR STATUS 



QUALIFY PROCESS! 



SUSPEND PROCESSOR! 



1^- 



START PROCESSOR! 



CREATE PROCESSOR OBJECTI 



(INSTRTI 



■;(INSTR)| 



(INSTR) 



(HARD).!. 



(HARD)I- 



•;(HARD)r 



(SOFty 



|PROCESSOR 

OBJECT ; 



LEGEND: INSTR 
HARD 

SOFT 



OPERATION IS A MACHINE INSTRUCTION (OPERATOR) 

OPERATION IS PERFORMED BY HARDWARE AS A RESULT OF 
CONDITIONS DETECTED BY THE PROCESSOR 

OPERATION IS IMPLEMENTED BY SOFTWARE (E.G. AN OPERATING 
SYSTEM) 



FIGURE 1SB OPERATIONS DEFINED ON A PROCESSOR OBJECT 



to this problem is described at the end of this 
chapter under "Object Locking." 

In the past, problems' like the first have been solved by 
introducing "privileged" and "user" instructions or modes of 
operation, which have the disadvantage that each user is 
either "universally privileged" or "universally restricted." 
Systems that generalize this scheme to three or more 
levels typically encounter similar problems in their blanket 
or graduated privilege schemes. Such schemes characteris- 
tically do not take individual procedure access requirements 
into account. 

In the object-oriented, capability-based environment of the 
432, several privilege and protection abstractions are 
realized using access descriptors, which act as privilege 
and protection "handles" for system objects. The 432 
approach is to grant a procedure read/write rights to 
explicit objects on an individual, need-to-know basis. By 
possessing an access descriptor to an object, a procedure is 
conferred the read/write rights specified by that access 
descriptor, and is thus capable of reading/writing the 
object. An access descriptor is thus sometimes called a 
capability. 

A running procedure context cannot read from or write to an 
object unless that procedure has an access descriptor for 
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that object. Moreover, the procedure cannot read to or 
write from the object accessed by the access descriptor 
unless that read or write privilege is expressly granted, as 
indicated in the access descriptor. Furthermore, the 
procedure cannot delete the access descriptor unless that 
right is explicitly indicated within the access descriptor 
itself. 

Thus, access descriptors provide: 

o Controlled access to a particular object; if a request 
to use an object matches the rights specified in the 
access descriptor for that object, the access descrip- 
tor maps a virtual address into a physical address, 
permitting access. 

o Read and/or write protection of the object by an 
instance of a procedure, independent of other objects, 
other procedures, and other instances of the same 
procedure. 

o Delete protection of the access descriptor itself. 

o Other object-specific information, such as system 
rights, an access descriptor validity check, and an 
indication of object storage allocation. 
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Since an object can be subsetted (using a refiner, as 
described later in this chapter) to obtain a smaller object, 
access descriptors provide a granularity of protection not 
found in "privilege-level" computer systems. 

Access Paths 

Many access descriptors can exist for the same object. Each 
access descriptor belongs to some (but may be copied and/or 
passed to another) procedure (context) , and defines the 
access rights of the procedure using it to access an object. 

For instance, Figure 2-4 shows three different access 
descriptors to the same object. Context A can read from 
Object A, but cannot write into it? Context B can write into 
Object A, but cannot read from it; and Context C can both 
read from and write into Object A. 

Figure 2-4. Different Access Paths and Rights to the Same 
Object. 

Segments — the Representations of Objects 

At the machine level, objects are represented by segments. A 

segment is characterized as being a contiguous block of 
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memory and having: 



o A base address. 

o A length, which can be up to 65536 bytes. 

o A base type and a system type, both of which depend on 
the intended use of the segment as an object. 

Relationship Between System Objects and Segments 

Every segment is an object, but the converse does not hold. 
Every object is either: 

o A segment, or 

o A subset of a segment (called a refinement) , or 

o A collection of segments and/or refinements. 

Both segments and system objects have these characteristics: 

o Each has a base address. If an object is a single 
segment, the base address is that of the segment. If 
an object is a group of segments, the base address is 
that of the "root" segment, i.e. the first in the 
access path. 
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o Each has a base type, which must be either of type data 
segment or type access segment. 

o Each has a system type, which can be generic (data 
segment or access list) , or can be specialized as a 
transformer, domain, dispatching port, context, 
operand stack, storage resource, etc. 

o Each is represented by, and accessed through, a segment 
descriptor in a segment table residing in memory. A 
segment descriptor encodes a segments base address, 
length, base type, system type, processor class, and 
other information. 

Object Networks. As an example of an object that is a 
collection of segments, consider the access segment (Object 
0) together with the objects Al, A2, and A3 referenced by 
its access descriptors. This collection defines a multiseg- 
ment object. Extending this concept, each of the objects Aj 
(j = 1, 2, 3) could itself be an access list referencinc 
objects Bjk (k = 1, 2, 3) . The resulting network of object.* 
Bll, B12, B32, B33, could then be considered an object 

Figure 2-5 depicts such an object. 

Figure 2-5. A Network of Objects as an Object. 
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Two-Level Object Typing 

Objects defined by the 432 architecture have two levels of 
typing: 

o A base type, which is either data segment or access 
segment. Data segments cannot contain access descrip- 
tors; access segments contain only access descriptors. 

o A system type, of which there are several: processor, 
process, domain, context, and dispatching port are but 
a few system types. 

Data Segments 

Data segments can contain anything but access descriptors. 
In fact, they can contain dummy copies of access descriptors 
for purposes of inspection, but the dummy copies will not 
"work" as access descriptors; if so referenced, the 432 
hardware will not permit the operation to take place. 

Data segments are used to hold instructions (as objects of 
system type instruction segment) , scalar data types, and any 
type of data structure except an access descriptor. In 
order to access a data segment, a procedure must have an 
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access descriptor for the data segment. 
Access Segments 

An access segment (sometim.es called an "access list") is a 
hardware-recognized array of access descriptors. In order 
to access an access segment, a procedure must have an access 
descriptor for the access segment itself. 

Symbology. In this manual, access segments are symbolized 
as shown in Figure 2-6. 

Figure 2-6. Access Segment Symbology. 

OBJECT LOCKING/EXCLUSION 
Object Locking 

Either software or hardware can lock (obtain exclusive 
access to) an object when required by a sequence of instruc- 
tions or microinstructions. Object can be locked in three 
ways : 

o Long-term software lock — used when a software 
operation requires that an object be locked for a 
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period of time longer than the duration of one 
instruction. Accomplished using the Lock Object/Un- 
lock Object instructions. 

Short-term software lock — used by a processor when 
executing an instruction that requires object locking 
for a period of time less than the duration of an 
instruction. 

Short-term hardware lock — used by a processor when 
performing an operation on its own behalf that 
requires an object to be locked. 
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CHAPTER 3 

INTRODUCTION TO 43203 INTERFACE PROCESSOR 

This introduction to the architecture of the Intel 43203 
Interface Processor (IP) includes four topics. The first 
introduces a basic I/O model. The second provides a brief 
discussion of the 43201 and 43202 General Data Processor 
(GDP) interface. (Refer to section 2 for a more detailed 
discussion) . The peripheral subsystem/IP interface is the 
third topic, which provides information concerning the 
software interface as well as the hardware interface. The 
final topic introduces the supplementary IP facilities, 
including the physical reference mode and the interconnect 
access mode. 

For a more detailed presentaion of the following concepts, 
refer to the iAPX Interface Processor Architecture Reference 
Manual, Order no. TBS) 

A BASIC I/O MODEL 

A typical application based on the iAPX 432 microprocessor 
family consists of a main system and one or more peripheral 
subsystems. Figure 3-1 illustrates a hypothetical configur- 
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ation that employs two peripheral subsystems. The main 
system hardware is composed of one or more iAPX 432 general 
data processors (GDPs) and a common memory that is shared by 
these processors. The main system software is a collection 
of one or more processes that execute on the GDP(s). 

A fundamental principle of the iAPX 432 architecture is that 
the main system environment is self-contained; neither 
processors nor processes have any direct contact with the 
"outside world." Conceptually, the main system is enclosed 
by a wall that protects objects in memory from possible 
damage by uncontrolled I/O operations. 

Figure 3-1 Main System and Peripheral Subsystems 

In an iAPX 432-based system, the bulk of processing required 
to support input/output operations is delegated to peripher- 
al subsystems; this includes device control, timing, 
interrupt handling and buffering. A peripheral subsystem is 
an autonomous computer system with its own local memory, I/O 
devices and controllers, at least one processor, and 
software. The number of peripheral subsystems employed in 
any given application depends on the I/O-intensiveness of 
the application, and may be varied with changing needs, 
independent of the number of GDPs in the system. 
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A peripheral subsystem resembles a mainframe channel in that 
it assumes responsibility for low-level I/O device support, 
executing in parallel with main system processor (s) . Unlike 
a simple channel, however, each peripheral subsystem can be 
configured with a complement of hardware and software 
resources that precisely fits application cost and perform- 
ance requirements. In general, any system that can communi- 
cate over a standard 8- or 16-bit microcomputer bus such as 
Intel^s Multibus design may serve as an iAPX 432 peripher- 
al subsystem. 

A peripheral subsystem is attached to the main system by 
means of an IP. At the hardware level, the IP presents two 
separate bus interfaces. One of these is the standard iAPX 
432 Packetbus and the other is a very general interface 
that can be adapted to most traditional 8-and 16-bit 
microcomputer buses. 

To support the transfer of data through the wall that 
separates a peripheral subsystem from the main system, the 
IP provides a set of software-controlled windows. A window 
is used to expose a single object in main system memory so 
that its contents m.ay be transferred to or from the periph- 
eral subsystem. 

The IP also provides a set of functions that are invoked by 
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software. While the operation of these functions varies 
considerably, they generally permit objects in main system 
memory to be manipulated as entities, and enable communica- 
tion between main system processes and software executing in 
a peripheral subsystem. 

It is important to note that both the window and function 
facilities utilize and strictly enforce the standard iAPX 
432 addressing and protection systems. Thus, a window 
provides protected access to an object, and a function 
provides a protected way to operate in the main system. The 
IP permits data to flow across the peripheral subsystem 
boundary while preserving the integrity of the main system. 

As figure 3-2 illustrates, input/output operations in an 
iAPX 432 system are based on the notion of passing messages 
between main system processes and device interfaces located 
in a peripheral subsystem. A device interface is considered 
to be the hardware and software in the peripheral subsystem 
that is responsible for managing an I/O device. An I/O 
device is considered to be a "data repository," which may be 
a real device (e.g., a terminal), a file, or a pseudo-device 
(e.g. , a spooler) . 

A message sent from a process that needs an I/O service 
contains information that describes the requested operation 
(e.g., "read file XYZ") . The device interface interprets 
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the message and carries out the operation. If an operation 
requests" input data, the device interface returns the data 
as a message to the originating process. The device 
interface may also return a message to positively acknow- 
ledge completion of a request. 

A very general and very powerful mechanism for passing 
messages between processes is inherent in the iAPX 432 
architecture. A given peripheral subsystem may, or may not, 
have its own message facility, but in any case, such a 
facility will not be directly compatible with the iAPX 
432''s. By interposing a peripheral subsystem interface at 
the subsystem boundary, the standard IP communication system 
can be made compatible with any device interface (see figure 
3-2) . 

Figure 3-2 Basic I/O Service Cycle 
Figure 3-3 Peripheral Subsystem Interface 
i2^X 432 INTEHFACE 

The IP exists in both the protected environment of the iAPX 
432, and the conventional environment of the external 
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subsystem. Because of this, an IP is able to provide a 
pathway over which data may flow between the iAPX 432 system 
and the external subsystem. The IP operates at the boundary 
between the systems, providing compatibility and protection. 
In this position, the Interface Processor presents two 
different views of itself, one to software and processors in 
the iAPX 432 environment and another to its external 
processor. 

From the iAPX 432 side, an IP looks and behaves very much 
like any other processor. It attaches to the processor 
packetbus in the same way as a GDP. Within the iAPX 432 
memory, the IP supports an execution environment that is 
compatible with, and largely identical to, the GDP. Thus, 
the IP recognizes and manipulates system objects represent- 
ing processors, processes, ports, etc. It supports and 
enforces the iAPX 432^s access control mechanisms, and 
provides full interprocess and interprocessor communication 
facilities. 

The principle difference between the two processors is that 
the GDP manipulates its environment in response to the 
instruction it fetches, while the IP operates under the 
direction of its external processor. Indeed, the IP may be 
said to extend the instruction set of the attached processor 
(AP) so that it may function in the environment of the iAPX 
432 system 
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PERIPHERAL SUBSYSTEM INTERFACE 

A peripheral subsystem interface (PSI) is a collection of 
hardware and software that acts as an adapter . that enables 
message-based communication between a process in the main 
system and a device interface in a peripheral subsystem (see 
figure 3-3) . Viewed from the iAPX 432 side, the peripheral 
subsystem interface appears to be a process. The peripheral 
subsystem interface may be designed to present any desired 
appearance to a device interface. For example, it may look 
like a collection of tasks, or like a collection of subrou- 
tines. 

Hardware 

The PSI hardware consists of an IP, an AP, and local memory 
(see figure 3-4 ) . To improve performance, these may be 
augmented by a DMA controller. The AP and the IP work 
together as a team, each providing complementary facilities. 
Considered as a whole, the AP/IP pair may be thought of as a 
logical I/O processor that supports software operations in 
both the main system and the peripheral subsystem. 

Attahed Processor — Almost any general-purpose CPU, such as 
an 8085, an iAPX 86 or an iAPX 88 can be used as an AP. The 
AP need not be dedicated exclusively to working with the. IP. 
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It may, for example, also execute device interface soft- 
ware. Thus, the AP may be the only CPU in the peripheral 
subsystem, or it may be one of several. 

As figure 3-4 shows, the AP is "attached" to the interface 
processor in a logical sense only. The physical connections 
are standard bus signals and one interrupt line (which would 
typically be routed to the AP via an interrupt controller) . 

Continuing the notion of the logical I/O processor, the AP 
fetches instructions, and provides the instructions needed 
to alter the flow of execution, and to perform arithmetic, 
logic and data transfer operations within the peripheral 
subsystem. 

Figure 3-4 Peripheral Subsystem Interface Hardware 

Interface Processor — The IP completes the logical I/O 
processor by providing data paths between the peripheral 
subsystem and the main system, and by providing functions 
that effectively extend the AP's instruction set so that 
software running on the logical I/O processor can operate in 
the main system. Since these facilities are software- 
controlled, they are discussed in the next section. 
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As figure 3-4 shows, the IP presents both a peripheral 
subsystem bus interface and a standard iAPX 432 Packetbus 
interface. By bridging the two buses, the IP provides the 
hardware link that permits data to flow under software 
control between the main system and the peripheral subsys- 
tem. 

The IP connects to the main system in exactly the same way 
as a GDP. Thus, in addition to being able to access main 
memory, the IP supports other iAPX 432 hardware-based 
facilities, including processor communication, the alarm 
signal and functional redundancy checking. 

On the I/O subsystem side, the IP provides a very general 
bus interface that can be adapted to any standard 8- or 16- 
bit m.icroprocessor bus, including Intel^s Multibus archi- 
tecture, as well as the component buses of the MCS-85 and 
iAPX 86 families. The IP is connected to the peripheral 
subsystem bus as if it were a memory component; it occupies 
a block of memory addresses up to 64K bytes long. Like a 
memory, the IP behaves passively within the peripheral 
subsystem (except as noted below) . It is driven by periph- 
eral subsystem memory references that fall within its 
address range. 

While the IP generally responds like a memory component, it 
also provides an interrupt request signal. The interface 
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processor uses this line to notify its AP that an event has 
occurred which requires its attention. 

To summarize, the AP and the IP interact with each other by 
means of address references generated by the AP and inter- 
rupt requests generated by the IP. Since the IP responds to 
memory references, other active peripheral subsystem agents 
(bus masters), such as DMA controllers, may obtain access to 
main system memory via the IP. 

Software 

IP Controller — The peripheral subsystem interface is 
managed by software, referred to as the IP controller- The 
IP controller executes on the AP and uses the facilities 
provided by the AP and the IP to control the flow of data 
between the main system and the peripheral subsystem. 

While there are no actual constraints on the structure of 
the IP controller, organizing it as a collection of tasks 
running under the control of a multitasking operating system 
(such as RMX-80 or iRMX-86) can simplify software develop- 
ment and modification. This type of organization supports 
asynchronous message-based communication within the IP 
controller, similar to the iAPX 432'*s intrinsic interpro- 
cessor communication facility. Extending this approach to 
the device interface as well results in a consistent, 
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system-wide communication model. However, communication 
within the IP controller and between the IP controller and 
device interfaces, is completely application-defined. It 
may also be implemented via synchronous procedure calls, 
with "messages" being passed in the form of parameters. 

However it is structured, the IP controller interacts with 
the main system through facilities provided by the interface 
processor. There are three of these facilities: execution 
environments, windows, and functions. 

Execution Hnvxronmsnts — The IP provides an environment 
within the main system that supports the operation of the IP 
controller in that system. This environment is embodied in 
a set of system objects that are used and manipulated by the 
IP. At any given time, the IP controller is represented in 
main memory by a process object and a context object. Like 
a GDP, the IP itself is represented by a processor object. 
Representing the IP and its controlling software like this 
creates an execution environment that is analogous to the 
environment of a process running on a GDP. This environment 
provides a standard framework for addressing, protection and 
communication within the main system. 

Like a GDP, an IP actually supports multiple process 
environments. The IP controller selects the environment in 
which a function is to be executed. This permits, for 
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example, the establishment of separate environments corres- 
ponding to individual device interface tasks in the periph- 
eral subsystem. If an error occurs while the IP controller 
is executing a function on behalf of one device interface, 
that error is confined to the associated process, and 
processes associated with other device interfaces are not 
affected. 

Windows — Every transfer of data between the main system 
and a peripheral subsystem is performed with the aid of an 
IP window. A window defines a correspondence, or mapping, 
between a subrange of peripheral subsystem memory addresses 
(within the range of addresses occupied by the IP) and an 
object in main system memory (see figure 3-5) . when an agent 
in the peripheral subsystem (e.g., the IP controller) reads 
a local windowed address, it obtains data from the assoc- 
.iated object; writing into a windowed address transfers data 
from the peripheral subsystem to the windowed object. The 
action of the IP, in mapping the peripheral subsystem 
address to the main system object, is transparent to the 
agent making the reference; as far as it is concerned, it is 
simply reading or writing local memory. 

Figure 3-5 Interface Processor Window 
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Since a window is referenced like local memory, any individ- 
ual transfer may be between an object and local memory, an 
object and a processor register, or an object and an I/O 
device. The latter may be appealing from the standpoint of 
"efficiency," but it should be considered with caution. 
Using a window to directly "connect" an I/O device and an 
object in main memory has the undesirable effect of propo- 
gating the real-time constraints imposed by the device 
beyond the subsystem boundary into the main system. It may 
seriously complicate error recovery as well. Finally, since 
there is a finite number of windows, most applications will 
need to manage them as scarce resources that will not always 
be instantly available. This means that at least some I/O 
device transfers will have to be buffered in local memory 
until a window becomes available. It may be simplest to 
buffer all I/O device transfers and use the windows to 
transfer data between local memory and main system memory. 

There are four IP windows that may be mapped onto four 
different objects. The IP controller may alter the windows 
during execution to map different subranges and objects. 
References to windowed subranges may be interleaved and may 
be driven by different processors in the peripheral subsys- 
tem. For example, the AP and a DMA controller may be 
driving transfers concurrently, subject to the same bus 
arbitration constraints that would apply if they were 
accessing local memory. 
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Functions — A fifth window provides the IP controller with 
access to the IP^s function facility. By writing operands 
and an opcode into predefined locations in this window^'s 
subrange, the IP controller requests the IP to execute a 
function on its behalf. This procedure is very similar to 
writing coiranands and data to a memory-mapped peripheral 
controller (e.g., a floppy disk controller). Upon comple- 
tion of the function, the IP provides status information 
that the IP controller can read through the window. The IP 
can perform transfer requests through the other four windows 
while it is executing a function. 

The IP's function set permits the IP controller to: 
o alter windows; 

o exchange messages with GDP processes via the standard 
IP communication facility; 

o manipulate objects. 

These functions may be viewed as instruction set extensions 
to the AP, which permit the IP controller to operate in the 
main system. The combination of the IP's function set and 
windows, the AP's instruction set, and possibly additional 
facilities provided by a peripheral subsystem operating 
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system, permits the construction of powerful IP controllers 
that can relieve the main system of much I/O-related 
processing. At the same time, by utilizing only a subset of 
the available IP functions, relatively simple IP controllers 
can also be built (in cases where this approach is more 
appropriate) . 

SUPPLEMENTARY INTERFACE PROCESSOR FACILITIES 

The preceding sections describe the IP as it is used most of 
the time. The IP provides two additional capabilities that 
are typically used less frequently, and only in exceptional 
circumstances. These are physical reference mode and 
interconnect access. 

Physical Reference Mode 

The IP normally operates in logical reference mode; this 
mode is characterized by its object-oriented addressing and 
protection system. There are times when logical referencing 

is impossible because the objects used by the hardware to 
perform logical-to-physical address development are absent 

(or, less likely, are damaged) . In these situations the IP 
can be used in physical reference mode. 

In physical reference mode, the IP provides a reduced set of 
functions. Its windows operate as in logical reference 
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mode, except that they are mapped onto memory segments 
(rather than objects) that are specified directly with 24- 
bit addresses. In this respect, physical reference mode is 
similar to traditional computer addressing techniques. 

Physical reference mode is most often employed during system 
initialization to load binary images of objects from a 
peripheral subsystem into main memory. Once the required 
object images are available, processors can begin normal 
logical reference mode operations. 

Interconnect Access 

In addition to memory, the iAPX 432 architecture defines a 
second address space called the processor-memory intercon- 
nect. One of the IP windows is sof tware-switchable to 
either space. In logical reference mode, the interconnect 
space is addressed in the same object-oriented manner as the 
memory space, with the IP automatically performing the 
logical-to-physical address development. In physical 
reference mode, the interconnect space is addressed as an 
array of 16-bit registers, with a register selected by a 24- 
bit physical address. 
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CHAPTER 4 



iAPX 432 PROCESSOR ENVIR013MENT DEFINITION 

This chapter describes the requirements placed on the 
logical structure of the iAPX 432 hardware environment. 
These requirements are concerned directly with the 
constraints of local memory, the type of data transferred 
(address, control, or data) , and the structure of the data 
types. 

The first section presents the information structure for an 
iAPX 432 system and includes a discussion of memory system 
requirements, physical addressing, data formats, data 
representation, and hardware error detection. The second 
section presents the elements of the processor packet bus 
and includes associated timing diagrams for Read, Write, and 
Access cycles. 

iAPX 432 INFORMATION STRUCTURE 

The iAPX 432 system contains both read/write (RAM) and read- 
only (ROM) memory. Any attached processor (8 bit or 16 bit) 
in the system can access all the contents of physical 
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memory. This section describes how information is repre- 
sented and accessed. 

Memory 

The iAPX 432 implements a two-level memory structure. The 
software system exists in a segmented environment in which a 
logical address specifies the location of a data item. The 
processor automatically translates this logical address into 
a physical address for accessing the value in physical 
memory. 

Physical Addressing 

Logical addresses are translated by the processor into 
physical addresses. Physical addresses are transmitted to 
memory by a processor to select the beginning byte of a 
memory value to be referenced. A physical address is 24 
binary bits in length. This results in a physical memory of 
over 16.5 Megabytes. 

Data Formats 

When a processor executes the instructions of an operation 
within a context, operands found in the segments of the 
context may be manipulated. An individual operand may occupy 
one, two, four, eight, or ten bytes of memory (byte, double 
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byte, word, double word, or extended word, respectively) . 
All operands are referenced by a logical address as 
described above. The displacement in such an address is the 
displacement in bytes from the base address of the data 
segment to the first byte of the operand. For operands 
consisting of multiple bytes, the address locates the low- 
order byte while the higher-order bytes are found at the 
next higher consecutive addresses. 

Data Representation 

An iAPX 432 convention has been adopted for representing 
data structures stored in memory. The bits in a field are 
numbered by increasing numeric significance, with the least- 
significant bit shown on the right. Increasing byte address- 
es are shown from right to left. Examples of the five basic 
data lengths used in the iAPX 432 system are shown in figure 
4-1. 

Figure 4-1 

Data Positioning 

The data structures shown in figure 4-1 may be aligned on an 
arbitrary byte boundary within a data segment. Note that 
more efficient system operation may be obtained when multi- 
byte data structures are aligned on double-byte boundaries 
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(if the memory system is organized in units of double 
bytes) . 

Requirements of an iAPX 432 Memory System 

The multiprocessor architecture of the iAPX 432 places 
certain requirements on the operation of the memory system 
to ensure the integrity of data items that can potentially 
be accessed simultaneously. Indivisible read-mod if y-write 
(RMW) operations to both double-byte and word operands in 
memory are necessary for manipulating system objects. When 
an RMW-read is processed for a location in memory, any other 
RMW-reads from that location must be held off by the memory 
system until an RMW-write to that location is received (or 
until an RMW timeout occurs) . Note that while the memory 
system is writing the RMW-write, any other types of reads 
and writes are allowed. Also, for ordinary reads and writes 
of double-byte or longer operands, the memory system must 
ensure the entire operand has been either read or written 
before beginning to process another access to the same 
location; e.g., if two simultaneous writes to the same 
location occurs, the set of locations used to store the 
operand could contain some interleaved combination of the 
two written values. 

iAPX 432 Hardware Error Detection 
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iAPX 432 processors include a facility to support ■ the 
hardware detection of functional errors. At INIT/ time each 
iAPX 432 processor is configured to operate as either a 
master or checker processor. A master operates in the 
normal manner. A checker places all output pins that are 
being checked into a high-impedance state. Thus a master 
and checker processor may be parallel-connected such that 
the checker is able to compare a master ^s output pin values 
to those computed in the checker. Any comparison error 
causes the checker to assert HERR/, FATAL/, and go idle. No 
further activity will occur at the disagreeing master- 
checker processor. 

Figure 4-2 Hardware Error Detection 
PACKET BUS DEFINITION 

This section describes and defines the significance of the 
19 signal lines that make up the processor packet bus, and 
the general schem.e by which tim.ing relationships on these 
lines are derived. Although this section defines all legal 
bus activities, the processors do not necessarily perform 
all allowed activities. 

The packet bus consists of 3 control lines: 
o Packet bus Request (PRQ) , 
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o Enable Buffer Outputs ( BOUT) . 



o Interconnect Status (ICS) , 

This bus also includes sixteen 3-state Address-Control-Data 
lines (ACD15 through ACDO) • PRQ has two functions whose use 
depends upon the application, i.e., PRQ either indicates the 
first cycle of a transaction on the processor component bus 
or the cancellation of a transaction initiated in the 
previous cycle. Of the three control lines, BOUT has the 
simplest function, serving as a direction control for 
buffers in large systems requiring more electrical drive 
than the processor components can provide. The ICS signal 
has significance pertaining to one of three different 
system conditions and depends on the state of the processor 
component bus transaction. The processor interprets the ICS 
input as an indication of one of the following: 

o Whether or not an interprocess communication (IPC) is 
waiting, 

o Whether or not the slave requires more time to service 
the processors request, 

o Whether or not a bus ERROR has occurred. 
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The Address/Control/Data lines emit output specification 
information to indicate the type of cycle being initiated, 
e,g,/ addresses, data to be written, or control informa- 
tion. They also receive data returned to the processor 
during reads. Details of the ACD line operation and the 
associated control lines are summarized below. 



ACD15 - ACDO (Address/Control/Data) — During the first 
cycle (Tl or Tvo (See Figure 4-3) of a processor 
component bus transaction (indicated by the rising 
edge of PRQ) , the high-order 8 ACD bits (ACD15 . . .ACD8) 
specify the type of the current transaction. 
In this first cycle, the low-order ACD bits 
(""^CD? . . . ACDO) contain the least significant eight bits 
of the 24 bit physical address. 

During the subsequent cycle (T2) , the remainder of the 
address is present on the ACD pins (aligned such that 
the most significant byte of the address is on ACD15 
through ACDS, the mid-significant byte on ACD7 through 
ACDO). If PRQ is asserted during T2, the access is 
cancelled and the ACD line is not defined. 



During the third cycle (T3 or Tw) of a processor 
packet bus transaction the processor presents a high 
impedance to the ACD lines for read transactions and 
Tw or T3 asserts write data for write transactions. 
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Processor Pocket Bus State Diagram 



Tvo 



Ti Tl T2 T3 Tv 



Tw 

INITIAL STATE NEXT STATE TRIGGER 

Ti Tl Bus cycle desired 

Ti No bus cycle desired 

Tl T2 Unconditional 

T2 T3 ICS high 

Tw ICS low 

Tl Cancelled, Access Pending 

Ti Cancelled, No Acccess Pending 

T3 T3 Additional transfer required 

Tw ICS low 

Tv All transfers completed if current cycle 

Tvo Overlapped write ^ 

Tv Ti If read or if write but no pending write 

Tl Current write with pending write 

T2 Current write with overlapped write 

Tvo T2 Overlapped write 

Tw Tw ICS Low 

T3 ICS High 

Figure SSeS( - State Diagram for Processor Packet Bus 

Lb) 



Once the bus has entered T3 or Tv, the sequence of 
state transactions depends on the type of cycle 
requested during the preceding Tl or Tvo, Accesses 
ranging in length from 1 to 32 bytes may be requested 
(see Table 4-1) . If a transfer of more than one double 
byte has been requested, it is necessary to enter T3 
for every double-byte that is transferred. After any 
transfer the processor may simply re-enter T3 or it 
may enter Tw for any number of cycles (as dictated by 
- ICS) and the number of double bytes remaining to be 
transferred. 

After all data is transferred, the processor enters 
either Tv or Tvo. Tvo can be entered only when the 
internal state of execution is such that the processor 
is prepared to accomplish an immediate write transfer 
(overlapped write) . During Tvo, the ACD lines contain 
address and specification information aligned in the 
same fashion as in Tl. If the processor does not 
require an overlapped write, the bus state moves to Tv 
(the ACD lines will be floating) . After Tv, a" new 
bus cycle can be started with Tl, or the processor may 
enter the idle state (Ti). 

ICS (Interconnect Status) — ICS has three possible inter- 
pretations depending on the state of the bus transac- 
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Table ^ffi ACD Specification Encoding 



tion {see -Figu&e — f€ST^ Notice that under most 
conditions ICS has IPC significance for more than one 
cycle. It is important to note that a valid low 
during any cycle with IPC significance will signal the 
processor that an IPC has been received. An iAPX 432 
processor is required to record and service only one 
IPC at a time. Logic in the interconnect system must 
record and sequence multiple (possibly simultaneous) 
IPC occurences to the processor. Thus the logic that 
forms ICS must accomodate global and local IPC 
arrivals and requests for reconfiguration as individ- 
ual events: 

1. Assert IPC significance on ICS for the arrival 
of an IPC. 

2. When the iAPX 432 processor reads interconnect 
address register 2, it will respond to one of 
the status bits for the IPC signalled on ICS 
in the following order: 

Bit 2 (l=reconf igure, 0=Do not reconfigure) 
Bit 1 (l=global IPC arrived, 0= No global IPC) 
Bit 0 (1= Local IPC arrived, 0= No local IPC) 
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3. The logic in the interconnect system must 

clear the highest order status bit that was 
serviced by the iAPX 432 processor and if 
additional IPC information has arrived the 
interconnect system logic must signal an 
additional IPC indication to the iAPX 432 
processor. 



PRQ (Processor Packet Bus Request) — PRQ is normally low 
and can go high only during Tl, T2 and Tvo. High 
levels during Tvo and Tl indicate the first cycle of 
an access. A high level during T2 indicates that the 
current cycle is to be cancelled. See ' ~ 

BOOT (Enable Buffered Outputs) — BOUT is provided to 
control external buffers when they are present. Table 
BOUT and the waveforms show its state under various 
conditions. Note that high to low transitions of BOUT 
will occur during T3 (when required) and low to high 
during Ti (when required). R'er^r Xo TASiLc. n"*^ j 



figure 4-3 State Diagram for Processor Packet Bus 



Table 4-1 ACD Specification Encoding 



Figure 4-4 Nominal Write Cycle Timing 
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LEVEL 






HIGH LOW 


STATE 


IPC 

STRETCH 
ERR 


NONE WAITING 
DON'T STRETCH 
BUS ERROR NO ERROR 


T1, Tl, T2* See Note. 
T3, Tw 
Tv, Tvo 



*Note: ICS has no significance in a cycle following a T2 where PRQ 
is asserted (cancelled access) or in any cycle during which 
HERR/ is asserted. 







ICS Interpretation 
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1 


Initiate access 


T2 


0 


Continue access 
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Cancel access 


T3 
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0 
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Tvo 
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Initiate overlapped access 



TABLE •^•3 QtiJiVt!!::!!"!^ - PRQ Interpretation 



BOUT 
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Low 


Write 
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Never 


Read 


Ti, Tl, T2 
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Table (""Mf"^ 1APX 432 Component Signalling Scheme 



Figure 4-5 Stretched Write Cycle Timing 
Figure 4-6 Minimum Write Cycle Timing 

Figure 4-8 Minimum Read Timing/No External Buffers (BOUT not 
used) 

Figure 4-7 Minimum Read Cycle (Buffered System) 

Figure 4-9 Minimum Faulted Access Cycle Timing (PRQ Cancel- 
lation) 

Processor Packet Bus Timing Relationships 

All timing relationships on the processor packet bus are 
derived from a simple scheme and related to Figure 4-3. Each 
timing diagram shown in the following pages provides a 
separate table illustrating the various system states during 
the cycle. This approach to transfer timing was designed to 
allow maximum time for the transfer to occur and yet 
guarantee hold time. 

Any agent connected to the processor packet bus is recogniz- 
ed as either a processor or a slave. Examples of processors 
are the GDP and the IP. A memory system provides an example 
of a slave. 
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In all tranfers between a processor and a slave, the data to 
be driven are clocked three-quarters of a cycle before they 
are to be sampled* The BOUT timing is unique because BOUT 
is intended as a direction control for external buffers. 

Detailed set-up and hold times depend on the processor 
implementation and can be found in the A.C. characteristics 
section. 

Note that in all transfers between a processor and a slave, 
data is clocked three quarters of a cycle before it is to be 
sampled. This allows adequate time for the transfer and 
ensures sufficient hold time after sampling. 

Table 4-2 ICS Interpretation 

Table 4-3 PRQ Interpretation 

m^KT « 4_A Tanrr»n 

Table 4-5 iAPX 432 Component Signaling Scheme 
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CHAPTER 5 



AN iAPX 432 l^nLTIPROCESSOR SYSTEM IMPLEMENTATION 

The prototype system described here is a simple but func- 
tional multiprocessor system that demonstrates the major 
characteristics of iAPX 432 system implementations. 

The first section of this Chapter deals with the processor 
component interconnection and inspects the associated 
Interconnect Status (ICS) logic, the Processor Request (PRQ) 
logic, and the Interconnect Processor (IPC) logic of iAPX 
432 systems. 

The second section describes the memory system logic and 
includes a discussion of the system clock generator, the 
PCLK generator, and a static byte-memory system. This 
section also discusses the important concepts of memory 
alignment, multibyte sequencing, and peripheral subsystem 
connections. 

SYSTEM DESCRIPTION 

The iAPX 432 demonstration system contains one General Data 
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Processor (GDP, consisting of an Intel iAPX 43201/432Q2 
device pair) / one Interface Processor (43203 IP device) , and 
a 2147-based static memory system. This system is capable of 
supporting a total of four attached processors. The IP 
connects via cabling to the Multibus interface of a 
peripheral subsystem. Figure 5-1 is a block diagram of the 
two-processor iAPX 432 system. Figure 5-2 shows the 
physical partitioning of the system. 

Each processor provides demultiplexing and buffering logic 
for the processor packet bus, IPC logic, and bus request 
logic. The memory system contains the system clock 
generator, the bus arbitration unit, the memory array, the 
memory sequencer, and bus buffering logic. 

Figure 5-1 Prototype System Block Diagram 

Figure 5='2 Physical System Partitioning 

PROCESSOR COMPONENT INTERCONNECTION 

iAPX 432 processor components share some common requirements 
in the system described. Refer to Figure 5-11 and Figure 
5-12 (Appended to this Chapter) for schematics of the two 
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Connect to 




MASTER 


vcc 


43201 


CLR/ 


vcc 




RDROM/ 


vcc 




ALARM/ 


vcc 


43202 


MASTER 


vcc 




CLR/ 


vcc 


43203 


HERR/ 


6ND 




CLR/ 


vcc 




ALARM/ 


VCC 



processor boards. 



Power supplied to iAPX 432 components is distributed across 
multiple Vqq 

and GND pins. Each power pin must be connected 
to the appropriate supply. Each V^c pin should be separate- 
ly bypassed through a short, low- inductance path to ground. 

Connections for CLKA and CLKB are made to all iAPX 432 
components. 

Each GDP or IP component requires interface logic to various 
circuits within the system. The following paragraphs will 
discuss the three specific areas of concern: 

o PRQ - ISC Logic 

o Bus Request/Grant Logic 

o Processor ID and IPC Logic 

Figure 5-3 Address Specification Demultiplexing 
Figure 5-4 Local Access Operation 
PRQ and ICS Logic 
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PRQ (Packet bus Request) and ICS (Interconnect Status) are 
the two signals that control data transfers on the processor 
packet bus. ICS is a processor output examined by a 
sequencer in managing the movement of information on the 
bus. PRQ is a processor input that may either signal an 
IPC, signal a bus error, or acknowledge the transfer of 
data. 

PRQ-Related Logic 

A TTL 74S175 register is employed as a state sequencer in 
decoding PRQ and generating several control signals. Figure 
5-6 demonstrates the generation of LDLOW and LDHIGH strobes 
for demultiplexing the processor packet bus address and 
specification fields. The rising ^dge of LDLOW strobes the 
specification field and the low 8 bits of the 24-bit 
physical address into the ADDRq through ADDR7 latch/bus 
drivers. The rising edge of LDHIGH strobes the mid-8 bits of 
the physical address into the ADDRs through ADDRp- latch/bus 
drivers. The uppermost 8 bits of the physical address are 
discarded in this system. The state sequencer also decodes 
an access to the interconnect address space (ACD15 = 1 when 
PRQ is asserted) and generates LOP (interconnect operation) 
as shown in Figure 5-5 Furthermore, cancelled accesses 
(denoted by two successive PRQ assertions) are detected by 
the sequencer, which generates the CANCL/ pulse. (See Figure 
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5-5.) Three consecutive assertions of PRQ cause an access 
to startf the CANCL/ signal to be asserted, and a new access 
to begin. (See Figure 5-6.) 



Figure 5-5 Cancelled Access 



Figure 5-6 Cancelled Access with Overlapped Access 



ICS-Related Logic 

ICS (Interconnect Status) is a combination of several 

signals that indicate either the status of a transfer, the 

occurrence of access errors, or the signalling of IPC 

(Interprocessor Communication) . The processor packet bus 

definition in the iAPX 432 component data sheets defines the 
time-dependent nature of ICS. 

Processor ID and IPC Logic 

After INIT/ is pulsed low, each processor reads interconnect 
address space (address 0) to obtain an 8-bit processor ID 
number. Processor number 0 is not allowed as a processor ID 
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code. The hardware at each processor location returns a 
unique 8-bit processor ID code. 

IPC signals are transferred to a processor board by the 
GLOBAL/ and LOCAL/ signals being held active for one clock 
cycle. Each type of IPC is latched at the respective 
processor. Interconnect address space (address 2) may be 
read by a processor to disclose whether a local or global 
(or both) IPC has been signaled. Once read, the IPC status 
bits are cleared one at a time. See Table 5-2 for the IPC 
bit encodings. 

A processor that signals an IPC will send either a global or 
a local IPC by writing to local address space register 2. 
Logic on each processor board decodes the specification 
field, interconnect address 2, and the processor ID field of 
the data packet double byte. A processor may signal any 
processor, all other processors, or itself. 

Table 5-2 IPC Register Bit Designation 

MEMORY SYSTEM LOGIC 

The memory system (Figure 5-7) contains a static memory 
system, an access sequencer, a bus arbiter, a PCLK generat- 
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T4-&tE S*"* 2* ^BBH^fflSSR - IPC Register Bit Designation 



or, and a clock generator for the system. 
System Clock Generator 

CLKA and CLKB for iAPX 432 components are 
generated at four times the component operating frequency by 
a crystal oscillator module that drives a Johnson counter. 
CLKA and CLKB are symmetrical square waves in quadrature (90 
degrees phase shift) . 

PCLK Generator 

PCLK, the timing signal for the system timer and process 
timer in iAPX 432 components, is generated by dividing CLKA 
by 1024. 



Figure 5-7 Memory system schematic 
Static Byte Memory System 

The static memory system demonstrates the requirements of an 
iAPX 432 system memory: alignment of data transfers, 
multibyte sequencing, and Bus Arbitration. Figure 5-7 a 
schematic of the memory system described. 
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Alignment 



Figure 5-8 depicts the transfer of a word operand (four 
bytes) . A processor may request this operand from memory 
without concern for its alignment in physical memory. The 
word operand consisting of bytes 0 to 3 is aligned to a 
double word boundary. The word operand consisting of bytes 3 
to 6 is not aligned. The processor packet bus specification 
field for each of these accesses is the same. (Only the 
physical starting addresses differ) . 

Physical address bit 0 indicates whether an access is 
aligned on a double-byte boundary (address bit 0 = G) or 
unaligned (address bit 0=1). When signal ALIGN/ is 
asserted, the memory system will perform the appropriate 
byte swapping to guarantee that right-justified data is 
transferred on the processor packet bus. 

In Figure 5-8 the double word operand reference to location 
3 demonstrates an unaligned reference to a word operand. In 
addition to the byte swapping requirement, references to two 
consecutive memory locations are required to transfer each 
double byte. Figure 5-9 shows how separately addressed 
parallel memory arrays are used to accomplish the transfer 
of any double-byte pair (aligned or unaligned) . 
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Figure 5-8 Operand References with Alignments 

Figure 5-9 Parallel Memory Array Organization 
MultiByte Sequencing 

The specification field of a processor packet bus transac- 
tion indicates the number of sequential bytes to be 
transferred at one time. The memory system uses the 
parallel bank memory structure just described, with 
appropriate control, to sequence multibyte accesses. 

A TTL 74S163 counter is loaded with a receded value for the 
length information in the specification field of a processor 
packet bus request. Accesses of encoded length 0 will cause 
the BYTE signal to be asserted. The 74S163 counts the 
number of double-byte accesses required to complete the 
transfer. At the end of a transfer the signal ERR is 
asserted, which indicates (via signal MERR) the ICS bus 
error significance (always errorless in this system) . 

The access sequencer generates one HOLD assertion for each 
unaligned double byte transferred. HOLD generates a wait 
state via the requesting processor's ICS pin. Aligned 
accesses and single byte accesses occur with no HOLD 
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penalty. 
Bus Arbiter 

The bus arbiter section of the memory system arbitrates 
requests from among the four processors for use of the bus 
and system memory. The arbiteruses BREQ4/ as the highest 
priority and BREQl/ as the lowest to resolve simultaneous 
requests. The resolved bus grant is returned to the 
highest-priority requester by asserting the appropriate 
BGRTn/ line. BGRTn/ remains asserted for the duration of 
processor "n's" access. 

Peripheral Subsystem Connection 

The IP board (Figure 5-12) connects via two buffered flat 
cables to the Multibus slave interface (Figure 5-10) in the 
peripheral subsystem containing the attached processor. The 
buffers and synchronization logic to generate the SYNC 
signal to the IP are located on the IP end of the cable 

The Multibus interface board employs an Intel 
8218 Multibus Arbiter to provide the peripheral subsystem 
interlock function. Even though the Multibus interface is a 
slave during data transfer operations, the IP uses its 
HLD/HDA pins to lock the Multibus (a function of a Multibus 
master) at certain key times. The HLD/HDA interlock is used 
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to prevent any peripheral subsystem processor from generat- 
ing a new transfer to or from the IP while it is in critical 
sections of its internal operations (e.g., altering windows 
into iAPX 432 memory) . 

Eight output port locations are used by the board. These 
ports are located at I/O addresses 0 through 7 and may be 
byte-addressed only. Table 5-3 outlines the assignment of 
functions to ports. 

Table 5-3 Peripheral Subsystem Dedicated Ports 

Chip select for the IP is decoded from ADR]_q through ADR]_3 
of the Multibus, allowing the IP to be memory-mapped within 
any 64K-byte portion of the Multibus. 
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Multibus Port 



Designated Function 



0 Deactivate INIT/ 

1 Activate INIT/ 

2 PuTse ALARM/ 

3 Reserved 

4 Reserved 

5 Reserved 

6 Reserved 

7 Reserved 
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iAPX 43201 



iAPX 43202 



VLSI GENEHAL DATA PROCESSOR 



Self-dispatching processors 
for software-transparent 
multiprocessing. 

Capability-based addressing 
and protection. 

2 to the 40th bytes of 
virtual address space. 



o Hardware implemented inter- 
process communication and 
dynamic storage allocation 

o High-level language di- 
rected instruction set with 
0-3 operand references. 

o Symmetrical support of all 
8-, 10-, 32-bit scaler data 
types and proposed IEEE 
standard 32-, 64-, and 
80-bit floating point. 



Functional redundancy 
checking mode for hard- 
ware error detection. 



o Object-based architecture 
for improved programmer 
productivity. 



The Intel iAPX 432 General Data Processor (GDP) consists of 
two VLSI devices, the 43201 and the 43202. These companion 
devices (Shown in Figures 1. and 2.) provide the general 
data processing facility of the iAPX 432 Micromainframe. 
The combination of VLSI technology and advanced architecture 
in the iAPX 432 results in mainframe functionality with a 
microcomputer form factor. The new object-based architec- 
ture significantly reduces the cost of large software 
systems and enhances their reliability and security. 

Software-transparent multiprocessing allows the user to 
configure systems matched to the required performance and 
provides an easy growth path. Hardware support for operat- 
ing systems and high level languages ease their implementa- 
tion. 

The GDP provides 2^0 bytes of virtual address space and 
supports 8-, 16-, and 32-bit machines with capability-based 
addressing and protection. In addition, a hardware-imple- 
mented functional redundancy checking mode is provided for 
the detection of hardware errors. 

The iAPX 43201 and iAPX 43202 are fabricated with Intel^s 
highly reliable +5-Volt, depletion load, N-channel, silicon 
gate HMOS technology and is packaged in a 64-pin Quad In- 
Line Package (QUIP) . 
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Figure 1. Instruction Decoder/Microinstruction Sequencer 



Figure- 2. Execution Unit 43202 Pin Assignment 



Figure 3. 43201 Block Diagram 



Figure 4. 43202 Block Diagram 



Figure 5, Hardware Error Detection 
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iAFX 432 GDP Functional Description 



The generalized data processor is organized internally as a 
three-stage microprogram-controlled pipeline. The first 
stage is the instruction decoder (ID) ; the second stage is 
the microinstruction sequencer (MS) ; and the third stage is 
the execution unit (EU) . 

The first two stages of the pipeline are physically located 
on the 43201 (Figure 3.). Each stage of the pipeline can 
be considered an independent subprocessor which operates 
until the pipeline is full and then halts and waits for more 
work to do. 

Instruction Decoder 

The first subprocessor of the pipeline is the ID, which 
performs the following functions: 

1. Receives macroinstructions 

2. Processes variable-length fields 

3. Extracts logical addresses 

4. Generates starting addresses for the microinstruction 
procedures 
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5. Generates microinstructions for simple operations 
Microinstruction Sequencer 

The second subprocessor in the pipeline is the MS, which 
performs the following functions: 

1. Issues microinstructions to the EU (43202) 

2. Executes microcode sequences out of an on-chip 3.5K x 
16-bit microcode ROM 

3. Responds to the bus control signals 

4. Invokes macroinstruction fetches 

5. Initiates interprocessor communication and fault 
handling sequences 

Execution Unit 

The 43202 contains the third stage of the GDP pipeline — the 
EU. (Refer to Figure 4.) This unit receives microinstruc- 
tions from the 43201 and routes them to one of the two 
independent subprocessors that make up the EU. These two are 
the data manipulation unit (DMU) and the reference genera- 
tion unit (RGU) . 
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The EU executes most microinstructions in one clock cycle. 
However, each of the subprocessors has an associated 
sequencer that may run for many cycles in response to 
certain microinstructions. Those sequencers are invoked for 
complicated arithmetic operations (in the DMU) and processor 
packet bus transactions (in the RGD) . 

The DMU contains the registers and arithmetic capabilities 
to perform the following functions: 

1. Hardware recognition of nine (S) data types 

2. Built-in state machine for 16-, 32-, 64-bit multiply, 
divide and modulus 

3. Control functions for 32-, 64-, and 80-bit floating 
point arithmetic. 

The RGU perform.s the following functions: 

1. Provides the translation of a 40-bit virtual address 
into a 24-bit physical address 

2. Provides for a hardware-enforced domain protection 
system (read, write, alter, accessed) 

3. Handles sequencing for 8-, 16-, 32-, 64-, and 80-bit 
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memory accesses 



4. Controls on-chip top-of-stack registers 

The 43201 and 43202 components, described above, together 
form the GDP. Figure 4b is a diagram that shows both units 
interfacing to the Packet bus as a single processor. 

Hardware Error Detection On iAPX 432 Processors 

iAPX 432 processors include a facility to support the 
hardware detection of functional errors. At INIT time, each 
iAPX 432 processor is configured to operate as either a 
master or a checker processor. A master operates in the 
normal manner. A checker places all output pins that are 
being checked in the high- impedance state. Thus, a master 
and checker are parallel-connected, pin for pin, so the 
checker can compare its master's output values with its own. 
Any comparison error causes the checker to assert HERR, and 
go idle (Refer to Figure 5.). No further activity can then 
occur at the disagreeing master-checker GDP pair. 



iAPX 43201/43202 Physical Interconnect 

Figure 6 illustrates the iAPX 432 microcomputer form factor 
using a Dual QUIP. This layout promotes the most efficient 
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utilization of the GDP. Also shown are the accessible GDP 
output/input signals. 

Figure 6. QUIP Layout 

432 Instructions 

Intel iAPX 432 instruction codes have been designed to 
minimize the space the instructions occupy in memory and 
still allow for efficient encoding. In order to achieve the 
ultimate in efficiency of storage the instructions are 
encoded without regard for byte, word or other artificial 
boundaries. The instructions may be viewed as a linear 
sequence of bits in memory, with each instruction occupying 
exactly the number of bits required for its complete 
specification. 

iAPX 432 processors view these instructions as composed of 
fields of varying numbers of bits that are organized to 
present information to the instruction decoder in the 
sequence required for decoding. A unified form for all 
instructions allows instruction decoding of all instructions 
to proceed in the same fashion. 

In general, GDP instructions consist of four main fields. 
These fields are called the class field, the format field, 
the reference field, and the opcode field. The reference 
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field, in turn, may contain several other fields, depending 
upon the number and complexity of the operand references in 
the instruction. The fields of a GDP instruction are stored 
in memory in the following format: 

The class field is either 4 or 6 bits long, depending on its 
encoding. The class field specifies the number of operands 
required by the instruction and the primitive types of the 
operands. The class field may indicate 0, 1, 2 or 3 
references. 

If the class field indicates one or more references, a 
format field is required to specify whether the references 
are implicit or explicit and their uses. 

In the case of explicit references the format field can 
indicate whether or not the reference is direct or indirect. 
Further, the format field may indicate that a single 
operand plays more than one role in the execution of the 
instruction. As an example, consider an instruction to 
increment the value of an integer in memory. This instruc- 
tion contains a class field, which specifies that the 
operator is of order two and that the two operands both 
occupy a word of storage, followed by a format field, whose 
value indicates that a single reference specifies a logical 
address to be used both for fetching the source operand and 
for storing the result, followed by an explicit data 
reference to the integer to be incremented, and finally 
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followed by an opcode field for the order-two operator 
INCREMENT INTEGER. It is possible for a format field to 
indicate that an instruction contains fewer explicit data 
references than are indicated by the instruction's class 
field. In such a case the other required data references 
are implicit references, and the corresponding source or 
result operands are obtained from or returned to the top of 
the operand stack. The use of implicit references is 
illustrated in the following example, which considers the 
high-level language statement 

A = A + B * C 

The instruction stream fragment for this statement consists 
of two instructions and has the following form: 



opcode reference format class 
< < Increasing address 

Assume that A, B, and C are integer operands. The first 
class field (the rightmost field in the picture above) 
specifies that the operator requires three references and 
that all three references are to word operands. 
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The first format field contains a code specifying two 
explicit data references. These references are to supply 
only the two source operands. The destination is referenced 
implicitly so that the result of the multiplication is to be 
pushed onto the operand stack. The second class field is 
identical to the first and specifies three required 
references by the operator. In addition, all three refer- 
ences are to word operands. The second format field 
specifies one explicit data reference to be used for both 
the first source operand and the destination. The second 
source operand is referenced implicitly and is to be popped 
from the operand stack when the instruction is executed. 

The reference fields themselves can be of various lengths 
and can appear in various numbers, consistent with their 
specification in the class and format fields. If implicit 
references are specified, reference fields for them will not 
appear. Direct references will require more bits to specify 
than indirect references. 

Following the class, format, and reference fields, the 
opcode field appears. The opcode field specifies the 
operator to be applied to the operands specified in the 
preceding fields. 
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Modes of Generation 



Figures 7 and 8 illustrate the two iAPX 432 system modes of 
generation, selector generation and displacement generation. 

The modes of selector generation are concerned with the 
object structure and how they are accessed by the operands. 
The four modes of selector generation shown are: 

1. Short Direct 

2. Long Direct 

3. Stack Indirect 

4. General Indirect 

The modes of displacement generation seek the physical 
location and displacement of objects within a given segment 
or segment. The four modes of displacement are: 

1. Scalar data Reference mode 

2. Record Item Reference Mode 

3. Static Vector Element Reference mode 

4. Dynamic Vector Element Reference mode 
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Microarchitecture example 



This subsection describes the general internal organization 
(microarchitecture) of the GDP and describes an example of 
its operation. The example is intended to provide a 
"feeling" for the microarchitecture and is by no means 
comprehensive. Subsequent sections will describe specific 
hardware elements. No attempt is made to describe the 
detailed techniques by which exceptional events are handled. 

The GDP pipeline starts when the ID passes starting address- 
es (determined by interpreting the instruction stream) to 
the MIS, which in turn feeds to the EU sequences of microin- 
structions that are appropriate to the current macroinstruc- 
tion. The EU then executes the microinstructions. Most 
micro instructions are executed by the EU in a single cycle 
each. However, both the RGU and the DMU contain state 
machines that are capable of multiple-cycle responses to 
certain microinstructions. In the case of those that 
require multiple cycles for execution, the MIS waits for 
notification of completion from the EU before advancing its 
state. The ID, however, can advance to the next macroin- 
struction and often goes on decoding without waiting for the 
MIS. 

With some knowledge of the instruction set code and the 
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hardware pipeline it becomes possible to understand the 
tasks facing each of the pipeline stages. 

Instruction Operator Set 

Refer to Table 1 for the iAPX General Data Processor 
operator set summary. 

Figure 9. GDP Packet Bus State Diagram 
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43201 PIN DESCRIPTION 



Processor Packet bus Group 

ACD-L5 ~ ACDqo (Address/Control/Data lines, Inputs) 

The processor Packet bus Address/Control/Data lines 
are the basic communication path between the GDP and 
its environment. These lines are always inputs to the 
43201 and are driven by either the 43202 or the 
external environment. Note that the 43201 must receive 
the specification byte from the 43202 during Tl of a 
bus transaction (Figure 9) . As a result, the ACD 
receivers must be capable of slave timing as well as 
processor timing (see processor Packet bus timing 
relationships for definition of processor and slave 
timing) . 

PRQ (Processor Packet bus Request, Input, high asserted) 

The PRQ input is used to initiate a transaction 
between the GDP and the bus interface. PRQ is normally 
held low by the 43202 whenever there is no transac- 
tion. PRQ is asserted high during the first cycle of a 
bus transaction and returns low during the second 
cycle if the transaction is to be completed. The GDP 
may cancel a bus transaction by continually asserting 
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* PRQ high (instead of returning it low) during the 
second cycle of the transaction. The GDP will cancel 
a transaction if a bounds or access rights violation 
for the transaction has been detected. PRQ is sampled 
on the rising edge of CLKB. 

ICS (Interconnect Status, Input, high asserted) 

The ICS input is continually monitored by the 43201 to 
determine the state of bus transactions. The inter- 
pretation of ICS depends on the present cycle of a bus 
transaction and will indicate one of the following 
states: 

1. Interprocessor communication (IPC) message 
waiting. 

2. Input data invalid, a streched access. 



4. Bus error in external environment. 

During idle periods (GDP not using the bus) the bus 
interface may signal the GDP on ICS that an Interpro- 
cessor communication message has been received. During 
a bus transaction, the bus interface will use ICS to 
handle bus protocol. (Refer to Figure 9 and Table 1 
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for the system relationship of the Packet bus group.) 



Intra-GDP Bus Group 

ul2_5...uIo (Microinstruction Bus lines, Outputs) 

These lines are used to transmit microinstructions 
from the 43201 to the 43202. These pins are high 
impedance in the checker state (Refer to Hardware 
Error Detection Group). They are monitored by the 
hardware error checking logic. 

IS5...IS0 (Interchip Status lines, Inputs) 

The 43201 receives information pertaining to micro 
program status from the 43202 over these lines. 

System Error Group 

FATAL/ (Fatal, Output, low asserted) 

FATAL/ is asserted by the 43201 under microcode 
control and is used by the GDP microcode to indicate 
to the system that the GDP cannot continue due to 
grossly incorrect information structures in memory. 
FATAL/ is synchronously asserted low and remains low 
until the processor is initialized. FATAL/ is not 
affected by the hardware checking logic. 
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ALAEM/ (Alarm signal, Input, low asserted) 

The ALARM/ input signals the occurrence of an unusual 
system-wide condition (such as power fail) . The 43201 
does not respond to ALARM/ until it has completed 
execution of the current 432 instruction , i.e., if 
any instruction is currently under execution. ALARM/ 
is active low and is sampled on the rising edge of 
CLKA. 

System-Wide Group 

INIT/ (Initialization, Input, low asserted) 

The INIT/ pin is used to establish initialization. 
INIT/ must be asserted low for at least 10 CLKA cycles 
before the initial state is reached to allow time for 
the 43201 to begin execution of a microcode sequence 
that initializes all of the 43201 and 43202 internal 
registers. Once this initialization sequence has been 
completed, normal operation begins. 

CLR/ (Clear, Input, low asserted) 

Assertion of CLR/ causes the 43201 to immediately trap 
to a microcode flow that halts the 43202, asserts 
FATAL/ and waits for a local IPC- 
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Hardware Error Detection Group 

MASTER (Master, Input, high asserted) 

The MASTER pin is used to place the processor in 
either master or checker mode. MASTER is sampled 
during initialization (INIT/ asserted) . If MASTER is 
asserted throughout initialization, the 43201 
functions normally and drives the microinstruction 
bus. If MASTER is low throughout initialization, 
microinstruction bus signals uIis-uIq go to their 
high-impedance state. A 43201 thus conditioned does 
not drive the microinstruction bus; rather, the bus is 
monitored and compares the data on the bus to its 
internally generated result, signaling disagreenient on 
its HERR/ line. MASTER should be tied to V^c for 
normal operation and pulsed low to enable hardware 
error checking and disable the bus (uIis-uIq) outputs. 

HERR/ (Hardware Error, Output, low asserted) 

HERR/ is a signal produced by the 43201 to indicate 
disagreement between the data appearing on the micro- 
instruction bus (uli5 - uIq) and the internally 
generated result of the 43201. HERR/ is asserted low 
when disagreement occurs and is valid during CLKA. 
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Clock Group 



CLKA, CLKB (Clock A, Clock B, Inputs) 

Clock A provides the basic timing reference for the 
43201. Clock B (CLKB) overlaps CLKA by nominally 1/4 
cycle (90 degrees phase shift) . All external signals 
are referenced to CLKA, Refer to the A. C. Electrical 
Characteristics for exact statement of timing rela- 
tionships. 

Testing Input 

RDROM/ (Read ROM, Input, low asserted) 

The RDROM input line is used to force a sequential 
read of Read-Only-Memory. When the RDROM/ line is 
asserted low throughout initialization (INIT/ 
asserted) , the 43201 goes into a special diagnostic 
mode. In this mode, the 43201 microinstruction 
sequencer steps through the 43201 microprogram ROM, 
sequentially displaying (but not executing) the 43201 
microprogram on the uI]_5-uIo lines. The sequencer 
continues to cycle through the microprogram ROM until 
INCR uA/ is no longer asserted. The INCR uA/ feature 
is useful for testing, but should not be used during 
normal operation since it could lead to unpredictable 
results. INCR uA/ should be tied to Vqq for normal 
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operation and only asserted low for testing (Powe 
ground, not connected) . 



^CC (4 pins) 



These pins supply +5 V + 10 % referenced to GND pins 



GND (5 pins) 



These pins supply ground reference for the 43201. 



N.C. (No Connection, 5 pins) 
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43202 PIN DESCRIPTION 



Processor Packet Bus Group 

ACD]_5-ACDo (Address/Control/Data lines. Inputs or Three- 
state Outputs, high asserted) 

The processor Packet bus Address/Control/Data lines 
are the basic communication path between the GDP and 
its environment. These pins are used three ways: 

1. They may indicate control information for bus 
transactions, 

2. they may issue physical addresses generated 
within by the GDP for an access, or 

3. they may transfer data (either direction) • 

The ACD pins are monitored by the hardware error 
checking logic when the 43202 is in checker mode and 
are conditionally in the high impedance mode. 

PRQ (Processor Packet bus Request, Three-state Output, low 
asserted) 

PRQ is used to indicate the presence of a transaction 
between the GDP and its external environment. Normally 
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low, the PRQ pin is brought high during the same cycle 
as the first double-byte of address information is 
being driven onto the ACD pins. PRQ remains high for 
only one cycle during the access, unless an address 
development fault occurs. The 43202 will leave PRQ 
high for a second cycle to indicate the GDP has 
detected an addressing or segment rights fault in 
completing address generation. PRQ is checked by the 
hardware error logic. PRQ is in a high impedance 
state when the 43202 is in checker mode (see MASTER 
description) . 

ICS (Interconnect Status, Input, low asserted) 

ICS is an indication to the 43202 from the bus 
interface circuitry concerning the status of a bus 
transaction. The interpretation of the ICS state is 
dependent upon the present cycle of a bus transaction 
and may indicate: 

1. Interprocessor communication (IPC) message 

waiting, 

2. Input data invalid, 

3. Output data not taken, 

4. Bus error in external environment. 
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During idle periods {when the GDP is not using the 
bus) the bus interface may signal the GDP on ICS an 
Interprocessor communication message has been 
received. During a bus transaction, the bus interface 
will use ICS to handle bus protocol, i.e., data not 
taken, or (for a read) data invalid. When the 43202 is 
in checker mode (see MASTER description) ICS is always 
asserted. 

BOOT (Enable Output Buffers, Output, high asserted) 

BOUT is used to control bus external transceivers to 
buffer the 43201, 43202 from the processor component 
bus load. Though not required, the use of buffers may 
be desired in systems with heavy loading. BOUT is 
asserted when information is to leave the 43202 on the 
ACD lines. 

Intra-GDP Bus Group 

ul2_5-uIo (Microinstruction lines. Inputs, high asserted) 

The uIis-uIq input lines provide the 43202 with 
microinstruction information sent from the 43201. 

ISg-ISQ (Microprogram Status lines. Outputs, high asserted) 
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The ISg-ISQ lines drive microprogram status informa- 
tion from the 43201 to the 43202. 

System Group 

PCLK/ (Processor Clock, Input, low asserted) 

PCLK/ is implemented to change the state of two 
processor timers. The affected timers are called the 
system timer and the service timer. Assertion of 
PCLK/ for one cycle causes the system timer to 
increment and the service timer to decrement. Asser- 
tion of PCLK/ for more than one cycle causes the 
system timer to be cleared and decrements the service 
timer. For proper operation PCLK/ must be unasserted 
for at least one cycle before being asserted. PCLK/ 
is synchronous with respect to CLKA, but is generally 
unrelated to other interface timings. 

CLK/ (Clear, Input, low asserted) 

The Clear (CLR/) input causes the 43202 to cease the 
execution of any multiple cycle microinstruction 
under way when CLR/ is asserted. 
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Hardware Error Detection Group 

MASTER (Master, Input, high asserted; 25 k nominal pullup 
on-chip) . 

The MASTER input determines whether the 43202 is to 
function as a master or a checker, MASTER is continu- 
ally sampled by an internal flip-flop. When MASTER is 
seen to have changed state, all output lines will be 
controlled appropriately (driven or allowed to float) 
within 2 cycles (Such a change in state will not 
result in a spurious HERR/ assertion) . The Checker 
mode affects the behavior of ACDis-ACDq, PRQ, and 
BOUT. ACD15-ACDQ and PRQ enter the high impedance 
state and BOUT is unconditionally low, 

HERR/ (Hardware Error, Output, low asserted). 

The HERR/ output indicates a hardware error has been 
detected. 

Clock Group 

CLKA, CLKB (Clock A, Clock B, Inputs) 

Clock A (CLKA) provides the basic timing reference for 
the 43202. Clock B (CLKB) overlaps CLKA by nominally 
1/4 cycle (90 degrees phase shift) . Refer to the A. C. 
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Electrical Characteristics for exact statement of 
timing relationships. All external signals are 
referenced to CLKA. Power, ground not connected. 

^CC (Power Supply, 4 pins) 

These pins supply +5 V +10%, referenced to GND pins. 
GND (Ground, 5 pins) 

These pins supply ground reference for the 43202. 
N.C. (No Connection, 7 pins) 
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Table-^^ ± 



General Data Processor Operator Set Summary 

Character Operators 

Move Character 
Zero Character 
One Character 
Save Character 

AND Character 
OR Character 
XOR Character 
XNOR Character 
Complement Character 

Add Character 
Subtract Character 
Increment Character 
Decrement Character 

Equal Character 

Not Equal Character 

Equal Zero Character 

Not Equal Zero Character 

Greater Than Character 

Greater Than or Equal Character 
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Convert Character to Short Ordinal 

Short-Ordinal Operators 

Move Short Ordinal 
Zero Short Ordinal 
One Short Ordinal 
Save Short Ordinal 

AND Short Ordinal 
OR Short Ordinal 
XOR Short Ordinal 
XNOR Short Ordinal 
Complement Short Ordinal 

Extract Short Ordinal 
Insert Short Ordinal 
Significant Bit Short Ordinal 

Add Short Ordinal 
Subtract Short Ordinal 
Increment Short Ordinal 
Decrement Short Ordinal 
Multiply Short Ordinal 
Divide Short Ordinal 
Remainder Short Ordinal 
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Equal Short Ordinal 

Not Equal Short Ordinal 

Equal Zero Short Ordinal 

Not Equal Zero Short Ordinal 

Greater Than Short Ordinal 

Greater Than or Equal Short Ordinal 

Convert Short Ordinal to Character 
Convert Short Ordinal to Ordinal 
Convert Short Ordinal to Temporary Real 

Short-Integer Operators 

Move Short Integer 
Zero Short Integer 
One Short Integer 
Save Short Integer 

Add Short Integer 
Subtract Short Integer 
Increment Short Integer 
Decrement Short Integer 
Negate Short Integer 
Multiply Short Integer 
Divide Short Integer 
Remainder Short Integer 

Equal Short Integer 
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Not Equal Short Integer 
Equal Zero Short Integer 
Not Equal Zero Short Integer 

Greater Than Short Integer 
Greater Than or Equal Short Integer 
Positive Short Integer 
Negative Short Integer 

Convert Short Integer to Integer 
Convert Short Integer to Temporary Real 

Ordinal Operators 

Move Ordinal 
Zero Ordinal 
One Ordinal 
Save Ordinal 

AND Ordinal 
OR Ordinal 
XOR Ordinal 
XNOR Ordinal 
Complement Ordinal 

Extract Ordinal 
Insert Ordinal 
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Significant Bit Ordinal 



Add Ordinal 
Subtract Ordinal 
Increment Ordinal 
Decrement Ordinal 
Multiply Ordinal 
Divide Ordinal 
Remainder Ordinal 

Equal Ordinal 

Not Equal Ordinal 

Equal Zero Ordinal 

Not Equal Zero Ordinal 

Greater Than Ordinal 

Greater Than or Equal Ordinal 



Convert Ordinal 
Convert Ordinal 
Convert Ordinal 



to Short Ordinal 

to Integer 

to Temporary Real 



Integer Operators 



Move Integer 
Zero Integer 
One Integer 
Save Integer 



Add Integer 
Subtract Integer 
Increment Integer 
Decrement Integer 
Negate Integer 
Multiply Integer 
Divide Integer 
Remainder Integer 

Equal Integer 

Not Equal Integer 

Equal Zero Integer 

Not Equal Zero Integer 

Greater Than Integer 

Greater Than or Equal Integer 

Positive Integer 

Negative Integer 

Convert Integer to Short Integer 
Convert Integer to Ordinal 
Convert Integer to Temporary Real 

Short-Real Operators 

Move Short Real 
Zero Short Real 
Save Short Real 
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Add Short Real - Short Real 
Add Short Real - Temporary Real 
Add Temporary Real - Short Real 
Subtract Short Real - Short Real 
Subtract Short Real - Temporary Real 
Subtract Temporary Real - Short Real 
Multiply Short Real - Short Real 
Multiply Short Real - Temporary Real 
Multiply Temporary Real - Short Real 
Divide Short Real - Short Real 
Divide Short Real - Temporary Real 
Divide Temporary Real - Short Real 
Negate Short Real 
Absolute Value Short Real 

Short-Real Operators 

Equal Short Real 

Equal Zero Short Real 

Greater Than Short Real 

Greater Than or Equal Short Real 

Positive Short Real 

Negative Short Real 

Convert Short Real to Temporary Real 
Real Operators 
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Move Real 

Zero Real 
Save Real 

Add Real - Real 

Add Real - Temporary Real 

Add Temporary Real - Real 

Subtract Real - Real 

Subtract Real - Temporary Real 

Subtract Temporary Real - Real 

Multiply Real - Real 

Multiply Real - Temporary Real 

Multiply Temporary Real - Real 

Divide Real - Real 

Divide Real - Temporary Real 

Divide Temporary Real - Real 

Negate Real 

Absolute Value Real 

Equal Real 

Equal Zero Real 

Greater Than Real 

Greater Than or Equal Real 

Positive Real 

Negative Real 

Convert Real to Temporary Real 
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Temporary-Real Operators 

Move Temporary Real 
Zero Temporary Real 
Save Temporary Real 

Add Temporary Real 
Subtract Temporary Real 
Multiply Temporary Real 
Divide Temporary Real 
Remainder Temporary Real 
Negate Temporary Real 
Square Root Temporary Real 
Absolute Value Temporary Real 

Equal Temporary Real 

Equal Zero Temporary Real 

Greater Than Temporary Real 

Greater Than or Equal Temporary Real 

Positive Temporary Real 

Negative Temporary Real 

Convert Temporary Real to Ordinal 
Convert Temporary Real to Integer 
Convert Temporary Real to Short Real 
Convert Temporary Real to Real 

Access Descriptor Movement Operators 
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Copy Access Descriptor 
Null Access Descriptor 

Rights Manipulation Operators 

Amplify Rights 
Restrict Rights 

Type Definition Manipulation Operators 

Create Public Type 

Create Private Type 

Retrieve Public Type Representation 

Retrieve Type Representation 

Retrieve Type Definition 

Refinement Operators 

Create Generic Refinement 
Create Typed Refinement 
Retrieve Refined Object 

Segment Creation Operators 

Create Data Segment 

Create Access Segment 
Create Typed Segment 



Create Access Descriptor 

Access Path Inspection Operators 

Inspect Access Descriptor 
Inspect Access 

Object Interlock Operators 

Lock Object 
Unlock Object 

Indivisibly Add Short Ordinal 
Indivisibly Add Ordinal 
Indivisibly Insert Short Ordinal 
Indivisibly Insert Ordinal 

Branch Operators 

Branch 

Branch True 
Branch False 

Branch Indirect 

Branch Intersegment 

Branch Intersegment without Trace 

Branch Intersegment and Link 



Context Communication Operators 

Enter Access Segment 
Enter Global Access Segment 
Set Context Mode 
Call Context 

Call Context with Message 
Return from Context 

Process Communication Operators 

Send 
Receive 

Conditional Send 
Conditional Receive 
Surrogate Send 
Surrogate Receive 
Delay 

Read Process Clock 

Processor Communication Operators 

Send to Processor 

Broadcast to Processors 

Read Processor Status and Clock 

Interconnect Operators 



Move to Interconnect 
Move from Interconnect 

(Note) Each of these operators is identical to the operator 
with the same assigned number and is specified by the same 
operator code. 
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lAPX 432 Timing/ Characteristics 



Figures 10 through 15 contain input/output timing, clock 
input specifications, error checking timing, initialization 
timing, and microcode interrogation timing for the 43201. 
Tables 2, 3, and 4 contain the A. C, D. C. , and capacitance 
specifications for the 43201. 

Figures 16 through 19 contain input/output timing, BOUT 
timing, and input clock timing for the 43202. Tables 5, 6, 
and 7 include the A. C, D. C. , and capacitance specifica- 
tions for the 43202. 

Table 2. 43201 D. C. Electrical Characteristics 
Table 3. A. C. Electrical Characteristics 
Table 4. 43201 Capacitance 

Figure 10. 43201 Output Timing Specification 
Figure 11. 43201 Input Timing Specification 
Figure 12, Clock Input Specification 
Figure 13. 43201 Hardware Error Check Timing 
Figure 14. 43201 Initialization Timing 



Figure 15. Microcode Interrogate Timing 



Table 5. 43202 DC Characteristics 



Table 6. 43202 AC Characteristics 



Table 7. 43202 Capacitance 



Figure 16. 43202 Output Timing Specification 



Figure 17. 43202 Input Timing Specification 



Figure 18. 43202 BOUT/ Timing Specification 
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/Ol ELECTRICAL CHARACT5RISTICS 



D.C. Characteristics 

(TA « 0 degrees C to 70 degrees C; VCC « 5V + 10%; VSS » 
OV; unless otherwise specified) "~ 



SYMBOL 


PARAMETER 


MIN. 


MAX* 


UNIT 


CONDS 


VILI (ISg..«ISQ} 


Input Low Voltage 
(ISg • • .ISq) 


-0.3 


+0.7 


V 




VIHI (ISg...ISQ) 


Input High 
Voltage 


3.0 


VCC+0.5 


V 




VILC 


Clock Input Low 
Voltage 


-0.3 


+0.5 


XT 

V 




VIHC 


Clock Input High 
Voltage 


VCC-1,0 


VCC+0.5 


V 




VXL (Remaining 
Inputs} 


Input Low Voltage 


-0.3 


+0,8 


V 




VTH (Remaining 
Inputs) 


Input High 
voJLtage 


2.0 


VCC+0.5 


V 




VOL (Micro- 
instruction 
Lines) 


Output Low 
Voltage (ulx) 


0 


+0.35 


V 


IOL= 


VUH iMlCrO"' 

Instruction 
Lines) 


Output High 
Voltage (ulx) 






V 


Tnw— 
-0.1mA 


VwJu 


WUCpuU XiwW 

Voltage 






V 

w 


2«0mA 


VOH 


Output High 
Voltage 


2.4 




V 


IOH= 
-0.4mA 


ICC 


Power Supply 
Current 




400 


mA 




IIL 


Input Leakage 
Current 




+10 


uA 


VIN=VCC 


ILO 


Output Leakage 
Current 




+10 


uA 


.45V< 
VOUT< 
VCC 



Capacitance 



SYMBOI. 


PAHAMETER 


TYP. 


UNIT 


CONDITION 


Cin 
Cout 


Input Capacitance 
Output Capacitance 


6 
12 


pP 


f C = IMH2 
VIN=VOCT=0V 




g^"!' ''rill/' ' ' " iiigSgSLB 




















symb6l pabameter 



vcc 

ICC 

VIL 
VTSL 



VILUI 
VlHllI 



VIL 
VIH 



VOL 



VOE 



VOL (ISc 

• • wXSq J 

voa (isg 

• • •XSa) 



Supply Voltage 
Supply Current 

Clock Input Low Voltage 
-Clock Input Hi Voltage 
for CLKA, CLKB inputs 

ol Input Low Voltage 
ul Input Hi Voltage 
for xoIq - ^1x5 

Input Low Voltage 
Input Hi Voltage 
for remaining pins 

Output Low Voltage 
8I0L s 2 IDA for ACDx, 
ISA/, HSRR/; 8 mA for 
BOOT 

Output Hi Voltage 
eiOH = 50 uA for ACDx? 
200 uA for BOUT 



Output Low Voltage 
ilOL « .1 siA 

Output Hi Voltage 
ilOH » -.1 mA 



Mm jax UNIT 

4,50 5.50 V 

455 mA 

-0.3 0.5 V 

VCC-1.0 VCC+0.5 V 



-0,3 0.7 V 
3.0 VCC+0.5 V 



•0.3 0.8 
2.0 VCC+0.5 



0.45 



2.4 VCC 



0.35 



3.25 VCC 



V 
V 



ILI Input Leakage +10.0 uA 

(Except MASTER) 

ILIl Input Leakage -400 uA 

MASTER input 

ILO Output Leakage +10.0 uA 

gVout = (0.45 Vcc) 



Capacitance 



SYMBOL 


PASAMETER 


TYP. 


UNIT 


CONDITION 


Cln 
Cout: 


Input Capacitance 
Output Capacitance^ 


6 

12 


pF 


f c = IMH2 
VIN=VOOT=0V 




iAPX 43203 
VLSI INTERFACE PROCESSOR 



o Fully protected I/O inter- 
face to 432 memory 



o Silicon operating system 
instruction set extensions 
for attached iAPX proces- 
sors 



o Buffered data path for 
high speed burst mode 
transfers 



o Multibus^ system com- 
patible interface 



o Initialization/diagnostic 
interface to 432 systems 



o Functional redundancy 

checking mode for hardware 
error detection 



o Multiple 43203''s per system 
provide incremental I/O 
capacity 



The Intel 43203 Interface Processor (IP) provides I/O 
facilities in iAPX 432 micromainframe systems employing 
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unprotected peripheral subsystems. An IP maps a portion of 
peripheral subsystem address space into iAPX 432 system 
memory. As does any iAPX 432 processor, the IP operates in 
an object-oriented, descriptor-based, transparent multipro- 
cessing environment. 

The 43203 is a VLSI device, fabricated with Intel's highly 
reliable +5 Volt, depletion load, N-channel, silicon gate 
HMOS technology, and is packaged in a 64-pin Quad In-Line 
Package (QUIP) . 

Figure 1. 43203 Pinout 
Figure 2. 43203 Logic Symbol 
Figure 3. 43203 Block Diagram 
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INTL 

oeC 

INH1 C 

yssC 

XACK/ C 

hldC 

hoac: 

SYNC C 
NAK/I 
BOUT I 

icsC 
vcci 

ACDisC 
ACD14 
ACpi3 CI 
AGD12 d 

ACD11 r" 
ACD10 ni 

ACDSCZ 
AC08[) 

vssCI 

ACQ? Q 

AC06 n 

ACOSC 
ACD4 

ACDSC 
ACD2[| 
ACD1 C 
ACDpr" 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
M 
12 
13 
14 
15 
16 
If 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 



64 
63 
62 
61 
60 
59 
58 
57 
56 
55 
54 
53 
52 
51 
50 
49 
48 
47 
46 
45 
44 
43 
42 
41 
40 
39 
38 
37 
36 
35 
34 
33 



Z3AD15 
~nAD14 
] AD13 
]Api2 

ZIadii 

I AD10 
3aD9 
tZlAD8 

3ycc 
3ad7 

IZIA06 
3 ADS 

AD3 
3AP2 

I]adi 

1 ADO 

3 vss 
Ipsr 

Z]WR/ 
Z]CS/ 

2 ALARM/ 
ZI PLR/ 

ZD HERR/ 

] FATAL/ 
1 PCLK/ 
] INIT/ 
I VCC 
3CLKA 
3CLKB 
1 VSS 



iAPX 432/03 INTERFACE PROCESSOR PIN CONFIGURATION 



V U U U N U 



ACD15 



432 ! 
PROCESSOR < 
BUS ! 



SYSTEM 
ERROR I 
GROUP' 



PRO 

TCSI 



BOUTIN 



a1arm7i — 

FATAL/1 ^ 



SYSTEM 
WIDE i { 
GROUP! 



CLOCK 
GROUP 



PCLK/I 
INIT/I 
CLR/I 

xTkai 

CLKB 



HARDWAREi — HERR, 

ERROR : 
DETECTION 

GROUP 



iAPX 432 SYSTEM 



432/^3! 

IP i 
LOGIC 
SYMBOL] 



A 



> 



AD15-0i 

•rBHENA 

■rcs7 
rwR7i 

■I ALE' 

•fOE 

JSYNC! 



■^-IDEN/: 



HLD 
HDA! 



•*|^IXACK7 
NAK/ 



■►nNTi 



■►rPSR; 



PS ' 
BUS 1 
GROUP 



ITIMING 



IBUFFER CONTROL! 
! GROUP : 

PS INTERLOCK " 
CONTROL GROUP 



ACKNOWLEDGE: 
GROUP 



INTERRUPT 

iPSRESET 



IPERIPHERAL SUBSYSTEM 



lAPX 4^2 
SYSTEM! 



SUBYSTEM 



ACD15. . .ACDd 




PRQ.ICS, BOUTI-^ 



ALARM. FATALI ^ 

pco^/imT — 



CLR.HERR 



> 





EXECUTION 
UNIT 





lAPX 
432 
CONTROL 




rPERIPHERALI 
I SUBSYSTEM' 
i CONTROL ! 



CLKA CLKB 
03 IP FUN CTI d N 4JbP LOCK DIAGRAM • 



AD15...AD0 



BHEN.CS,WR 



'ALE, OE, DEN 
HLbTHD'A 



,INH1,XACK, NAK 
ilNT 



Functional Description 



This data sheet describes the iAPX 432 Interface Processor 
(IP) Component. It is oriented toward hardware designers of 
iAPX 432 systems. iAPX 432 architectural information is 
provided in the Intel iAPX 432 General Data Processor 
Architecture Reference Manual (Order No. 171860) . Detailed 
information about the IP is contained in the Intel iAPX 432 
Interface Processor Architecture Reference Manual (Order No. 
171863-001) . The Intel iAPX 432 Component User's Guide 
(Order No. 171861) provides additional hardware support 
information. 

The IP, operating in conjunction with an Attached Processor 
(AP) , forms the logical I/O processor of an iAPX 432 system. 
The IP acts as a slave to the AP, mapping a portion of the 
AP's peripheral subsystem address space into iAPX 432 system 
memory with the same protection mechanisms as any iAPX 432 
processor. Five peripheral subsystem (PS) memory subranges 
may be mapped into iAPX 432 memory segments. These five 
windows (labeled 0 through 4) allow the AP to reference iAPX 
432 memory with logical addresses or, in special circum- 
stances, with direct 24-bit physical addresses. 

The IP does not execute instructions from an iAPX 432 memory 
segment, but rather accepts function requests from the AP 
and performs the specified operations in the iAPX 432 
system. Window 4 is designated for this function. 
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The AP may reference operands in iAPX 432 memory in random 
mode (random addressing order) or buffered mode (sequential 
addressing order) • Only window 0 can be used in buffered 
mode. It contains a 16-byte FIFO buffer which postwrites- 
/prefetches data. 

Window 1 may be used to reference the iAPX 432 interconnect 
address space when the IP is in physical mode. 

The sections of this data sheet are: 

o iAPX 43203 Pin Summary 

o 43203 Electrical Characteristics 

o Interfacing Peripheral Subsystems to the IP 

o IP/GDP Operator Comparison 

Table 1. 43203 Interface Processor Pin Summary 
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1APX 43203 INTERFACE PROCESSOR PIN SUMMARY 
432 SYSTEM SIDE 



PIN GROUP 


PIN NAME 


DIRECTION 


HARDWARE ERROR DETECTION 


PROCESSOR 


ACD15...AC00 


I/O 


X 


PACKET BUS 


PRQ 


0 


X 


GROUP 


ICS 


I 






BOUT 


0 




SYST£M 


ALARM/ 


I 




ERROR GROUP 


FATAL/ 


0 (I at I 


nitialization) 




CLR/ 


I 




SYSTEM-WIDE 


PCLK/ 


I 




GROUP 


INIT/ 


I 





SYSTEM CLOCK 


CLKA 


I 


GROUP 


CLKB 


I 


HARDWARE ERROR 


HERR/ 


0(1 at Initialization) 


DETECTION GROUP 





PERIPHERAL SUBSYSTEM SIDE 



PIN GROUP PIN NAME DIRECTION HARDWARE ERROR DETECTION 

PERIPHERAL AD15...AD0 I/O X 

SUBSYSTEM BHEN/ I 

BUS GROUP CS/ I 

WR/ I 

PS TIMING GROUP ALE I 

OE I 

SYNC I 



PS BUFFER CONTROL 


DEN/ 


0 


X 


GROUP 








PS INTERLOCK GROUP 


HLD 


0 


X 




HDA 


I 




PS SYNCHRONIZATION 


XACK/ 


0 


X 


GROUP 


NAK/ 


0 


X 




INHl 


0 


X 


PS INTERRUPT GROUP 


INT 


0 


X 


PS RESET GROUP 


PSR 


0 


X 



43203 Pin Description 



Processor Packet bus Group 

The following pins, shown in Table 2, fully conform to 
the specification in the iAPX 432 Processor Packet bus 
definition of the iAPX 432 Component User^s Guide . The 
IP is capable of all defined state transitions. It 
uses only a subset of the allowable data transfer 
lengths: operands of 1, 2, 4, 6, and 8 bytes are 
supported. Figure 4 illustrates the Processor Packet 
bus states for the iAPX 43203 and also conforms to the 
Packet bus definition. 

Table 2. Processor Packet bus Group 

Figure 4. Processor Packet Bus State Diagram for iAPX 43203 

System Error Group 

ALARM/ (Alarm, Input, low asserted) 

The ALARM/ input signals the occurrence of an unusual 
system-wide condition such as power failure. ALARM/ is 
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r 



1APX 43203 PIN DESCRIPTION 



(07 



Processor Packet Bus Group 



The following pins fully conform to the specification in the iAPX 432 
Processor Packet Bus Definition of the iAPX 432 Component User's Guide . The 
IP is capable of all defined state transitions. The 43203 uses only a subset 
of the allowable data transfer lengths: operands of 1,2,4,5, and 8 bytes are 
supported. 



11^ 



PIN NAME 



I/O 



PRQ 
ICS 

BOUT 



DESCRIPTION 



ACD15...ACD0 I/O 



jacket Request 
interconnect S^tatus 

Enable External Buffers for Output 
Address, Control, and Data Bus 




1 



Asserted High 



Asserted High I 



Processor PackeC Bu3 State DiagTam 




.; INITIAL STATE 



Ti 



Tl 



T2 



T3 



Tv 



Tyo 



NEXT STATE 

; - Tl • 

T1 



12 



T3 
Tw 
Tl 
TI 



T3 
Tw 
Tv 



Tl 
Tl 

J2. 



T2 



1^ 
73 



TRIGGER 

Bus cycle desired 
No bus cycle desired 



Unconditional 



ICS high 

ICS low . ^ 

Cancel led,7^^^^]5 f^-^^'^Z , 
■jVe€6S^(^g; yice I Screes'- pe>^<,n<^ 



Additional transfer required 
ICS low 

All transfers completed if current cycle 

o^zjr\c( :p'pc>3 u/r .' ^ c • 



is lead or If write but no pending write 
Current write with pending write 
Current write with overlapped write 



Overlapped write 



, . I ; I . I } ; ' 




I 



sampled on the rising edge of CLKA, 

FATAL/ (Fatal, Output, low asserted) 

FATAL/ is asserted by the IP under microcode control 
when the processor is unable to continue due to 
various error or fault conditions. Once FATAL/ is 
asserted, it can only be reset by assertion of INIT/ 
(no hardware error checking) . 

System Wide Group 

CLR/ (Clear, Input, Low asserted) . 

Clear Hardware Error. CLR/ is designed to be used in 
a system employing Hardware Error Detection. Assertion 
of CLR/ results in a microprogram trap which causes 
the IP to immediately terminate any bus transactions 
or internal operations which may be in progress at the 
time of the error and start a microsubroutine written 
to handle that situation. Once the service routine has 
been started, it cannot be interrupted by a second 
CLR/ assertion. Response to CLR/ can only be reenabled 
by assertion of the INIT/ pin. Normally, after a 
hardware error fault the microcode will execute its 
hardware error routine and then wait for an IPC which 
will cause it to reset the IP under microprogram 
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control. 



After the CLR/ pin is asserted, the IP master and 
checkers will try to "sync up" to each other. The 
earliest time that the components can be assumed to be 
resynchronized again is at the beginning of the fourth 
cycle after CLR/ is asserted. 

CLR/ is sampled by the IP on the rising edge of CLKA. 

PCLK/ (P Clock, Input, low asserted) 

Assertion of PCLK/ for one cycle causes the internal 
timers in the IP to "tick" (process timer decrements 
and system timer increments) . Assertion of PCLK/ for 
two or more cycles causes the system timer to be 
reset. 

INIT/ (Initize, Input, low asserted) 

Assertion of INIT/ causes the internal state of the IP 
to be reset and start execution of the initialization 
microcode. INIT/ must be asserted for a minimum of 8 
clock cycles. After the INIT/ pin is returned to its 
nonasserted state, IP microcode will initialize all of 
the internal registers and windows and will wait for a 
local IPC. 
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During the first two clock periods that the INIT/ pin 
is asserted the HERR/ pin will be sampled to determine 
whether this IP is to be a master or a slave proces- 
sor. At this time, if it is a master, the IP will 
enable all of its hardware error detected signals so 
that they will be valid when INIT/ goes high. 

System Clock Group 

CLKA, CLKB (Clock A, Clock B, Inputs) 

CLKA provides the basic timing reference for the IP. 
CLKB follows CLKA by one quarter cycle and is used to 
assist internal timings. 

Hardware Detection Group 

HERR/ (Hardware Error Output, low asserted) (Open Drain 
Output) (Master Input, low asserted) 

Asserrtion of the HERR/ pin by the IP indicates that 
the IP has encountered a hardware error, either as a 
checker checking a master or as a master checking 
itself. HERR/ is asserted the cycle following the 
internal detection of a hardware error except for pins 
AD15-AD0 where it may be up to five clocks. Because 
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of the asynchronous nature of hardware error detection 
on the AD pins (see AD pin description) , HERR/ may 
tend to be asynchronous. For this reason when using 
HERR/ it is recommended that this pin be synchronized 
externally. 

After HERR/ has been asserted for a cycle it is 
released for the next cycle to allow an external 
pullup resistor to bring it high again. After that 
cycle, the processor may reassert HERR/. Upon 
assertion of HERR/ the chip select will become 
deselected. 

While INIT/ is asserted HERR/ carries information 
regarding whether the IP is to perform hardware error 
detection on the peripheral subsystem side. If the pin 
is high, the IP will configure as a checker. If the 
pin is low, the IP will configure as a master. HERR/ 
must provide the master/checker information for at 
least two cycles preceding the rising edge of INIT/. 

Peripheral Subsystem Bus Group 

AD15-ADQ (Address/Data, Input/output) 

These pins constitute a multiplexed address and data 
input/output bus. When the attached processor bus is 
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idle or during the first part of an access, these pins 
normally view the bus as an address. The address is 
asynchronously checked to see if it falls within 
(matches) any one of the five window address ranges. 
The address is latched on the falling edge of ALE 
thereby maintaining the state of a match or no match 
for the remainder of the access cycle. The addresses 
are then unlatched on the falling edge of OE. 

Once SYNC has pulsed high, the AD15-AD0 pins become 
data input and output pins. When WR/ is high (read 
mode) , data is now accessed in the IP and the output 
buffers are enabled onto the AD pins if the OE is 
asserted. When WR/ is low (write mode) , data is 
sampled by the IP after the rising edge of SYNC during 
the CLKA high time (refer to the discussion of 
programmable interface timing) • 

The address is always a 16-bit unsigned number. Data 
may be either 8 bits or 16 bits as defined by BEEN/ 
and ADq. 8-bit data may be transferred on either the 
high (AD15-AD8) or the low (AD7-ADQ) byte. When 8-bit 
data is transferred on the high or low byte, the 
opposite byte is 3-stated. Twenty-bit addresses are 
accommodated by the external decoding of the addition- 
al address bits and incorporation in the external CS/ 
logic. 
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During the clock state in which write data is sampled, 
data must be set up before the rising edge of CLKA and 
must be held until the falling edge of that CLKA, Read 
data is driven out from a CLKA high and should be 
sampled on the next rising edge of CLKA. 

Hardware error detection sampling is not done syn- 
chronously to CLKA. It is sampled by the falling edge 
of the OE pin. The internal AD pin hardware error 
detection signal is then clocked and output on the 
HERR/ pin. At this point it may still not be syn- 
chronous with CLKA and should be externally synchron- 
ized. 

BHEN/ (Byte High Enable, Input, low asserted) 

This pin, together with ADq, determines whether 8 or 
16 bits of data are to be accessed, and if it is 8 
bits, whether it is to be accessed on the upper or 
lower byte position. This pin is latched by the 
falling edge of ALE and unlatched by the falling edge 
of OE. BHEN/ and ADq decode as follows: 



BHEN/ ADq 



DESCRIPTION 



0 



0 



16-bit access 



0 



1 



8 bits on upper byte. 



119 



lower byte tristated 

10 8 bits on lower byte, 

upper byte tristated 

118 bits on lower byte, 

upper byte tristated 

CS/ (Chip Select, Input, Low Asserted) 

Chip Select Specifies that this IP is selected and 

that a read or write cycle is requested. This pin is 

latched by the falling edge of ALE and unlatched by 
the falling edge of OE. 

WR/ (Write, Input, low asserted) 

This pin specifies whether the access is to be a read 
or a write. WR/ is asserted high for a read and 
asserted low for a write. This pin is latched by the 
falling edge of ALE and unlatched^ by the falling edge 
of OE. 

PS Timing Group 

ALE (Address Latch Enable, Input, rising- and falling-edge- 
triggered) 
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The rising edge of ALE sets a flip-flop which enables 
Transfer Acknowlege (XACK/) to become active. The 
falling edge of ALE latches the address on the AD^s-ADq 
pins and latches WR/, BHEN/ and CS/. 

OE (Data Output Enable, Input, high asserted) 

During a read cycle the OE pin enables read data on to 
the AD15-AD0 pins when it is asserted. During a read 
or write cycle the falling edge of OE signifies the 
end of the access cycle. Specifically, the falling 
edge of OE does three things: 

1. Resets the XACK/ enable flip-flop, thereby 
terminating XACK/. 

2. Terminates DEN/ (if read cycle) . 

3. Opens address latches WR/, BHEN/, and CS/. 

SYNC (Synchronized Qualifier Signal, Input, high asserted) 

A rising edge on this signal must be synchronized to 
the IP CLKA falling edge. This signal qualifies the 
address, BHEN/, CA/ and WR/ indicating a valid 
condition. SYNC also initiates any internal action on 
the IP^s part to process an access. It starts the 
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request for data to the IP in a read access. In a 
write access, data is expected one or two CLKA^s after 
SYNC pulses high. At initialization time, IP micro- 
code sets the write sample delay. However, this can 
be modified to one clock cycle by making a function 
request to the IP to change the write sample delay. 

When the hold/hold-acknowledge mechanism of the IP is 
used, and once HDA has pulsed high, a SYNC pulse is 
required to qualify the hold acknowledge since the HDA 
pin can be asynchronous. 

PS Buffer Control Group 

DEN/ (Data Enable, Output, low asserted) 

This pin enables external data buffers which would be 
used in systems where the address and data are not 
multiplexed as they are in a Multibus system. DEN/ 
assertion begins no sooner than the CLKA high time of 
the first clock of SYNC assertion if a valid, mappable 
address range is detected. It is terminated with the 
falling edge of OE. In a write access, it is also 
terminated after XACK assertion. 
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PS Interlock Group 



HLD (Hold Request, Output, high asserted) 

The hold/hold-acknowledge mechanism is an interlocking 
mechanism between the peripheral subsystem and the IP. 
Hold is used by the IP to gain control of the subsys- 
tem bus to ensure that no subsystem processors will 
make an access to the IP while it alters internal 
registers. 

This signal is put out synchronously with the rising 
edge of CLKA. Hardware error detection sampling 
occurs during CLKA low time. 

In special cases it may not be necessary to use the 
ELD function interlocking. In this case HDA can be 
tied high and no SYNC pulse will be required for HDA 
qualification. The hardware detects this condition by 
noting that the HDA pin was high a half clock before 
HLD requests a hold. In this mode the HLD output 
still functions and can be monitored if desired. 

HDA (Hold Acknowledge, Input, high asserted) 

HDA is asserted by the peripheral subsystem when the 
IP^s request for a hold has been granted. This pin 
need only be a high pulse and can be asynchronous to 
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CLKA. This pin must be followed by a SYNC pulse in 
order to synchronously qualify it. 

PS Synchronization Group 

XACK/ (Transfer Acknowledge, Output, low asserted) 

XACK/ is used to acknowledge that a data transfer has 
taken place. 

For random or local accesses, XACK/ indicates that a 
transfer to or from iAPX 432 memory has completed. 

For buffered accesses where the XACK-Delay is not in 
the advanced mode, XACK/ signifies that the transfer 
from/to the pref etch/postwr ite buffer in the IP has 
been completed. 

For buffered accesses which use advanced acknowledge 
mode (XD=0) the formation of an advanced XACK/ signal 
is requested. This allows the possibility of inter- 
facing to the peripheral subsystem without wait 
states. The acknowledge will be advanced if the 
access is a read operation and the buffer contains the 
required data or the access is a write operation and 
the buffer contains sufficient space to accept the 
write data. In addition, the access must be valid. 
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If XACK/ is preceded by a low pulse on NAK/, then 
XACK/ signifies that the access encountered a fault. 
If the access was a random access, other than window 
#4, the window will be placed in the faulted state and 
any further accesses to this window will be ignored by 
the IP. 

If the IP is programmed to be in advanced acknowledge 
mode (XD=0) and XACK/ is not returned before the 
peripheral subsystem issued SYNC, then XACK/ will be 
postponed until valid data has been established on the 
AD15-AD0 bus. 

Five conditions affecting XACK/ behavior: 

1. XACK-Delay, user programmable through an IP 
function request. This parameter establishes 
the minimum operating XACK-delay with respect 
to the SYNC signal. 

2. XACK-enable-f lip-flop, set by the rising edge 
of the ALE signal and reset by the falling 
edge of the OE signal. 

3. Internal IP Registers. These are used to 
determine validity of the peripheral subsystem 
access and establish access modes. 
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4. 



Type of access behavior: Random, Local or 
Buffered. 



5. Bus Faults, non existant memory, etc. 

Hardware error detection occurs during the first clock 
of SYNC assertion. 



NAK/ Negative Acknowledge, Output, low asserted) 

This signal precedes XACK/ by one half clock cycle in 
order to qualify it as a negative acknowledge. This 
pin pulses low for only one clock period. 



When the IP is in physical mode and making a local 
access, the use of negative acknowledge may be used to 
indicate that the access was made to nonexistant local 
address space. This will allow determination of the 
system configuration by a subsystem processor at 
system initialization time. 



This pin could be used to set a status bit and cause a 
special interrupt to transmit the information back to 
the subsystem. 



This signal is synchronously driven from the falling 
edge of CLKA. Hardware Error Detection occurs during 
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CLKA high. 



INEI (Inhibit, Output, high asserted) 

This pin is asynchronously asserted by non-clocked 
logic when a valid mappable address range is detected. 
It can be used to override other memories in the 
peripheral subsystem whose address space is overlapped 
by an IP window. After initialization, the microcode 
sets the INHI mode for each window by loading regis- 
ters in the IP for each window. Once the subsystem is 
allowed to make a function request, it can selectively 
disable or enable the inhibit mode on each window. 
This pin is gated off by CS/. 

The selection of the inhibit mode for window 0, when 
in buffered mode, causes a corresponding built-in 
XACK-delay which delays the acknowledge from going 
active until two clock periods after the rising edge 
of SYNC. This was done to facilitate most Multibus 
systems that use INHI which require that the acknow- 
ledge be delayed. When the Advanced XACK/ mode is 
programmed, the inhibit mode should not be used on 
window 0 when in buffered mode, since the acknowledge 
will not be effectively delayed. 

Hardware error detection occurs during the first clocK 
of SYNC assertion. 
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PS Interrupt Groap 



INT (Interrupt, Output, high asserted) 

This output is a pulse 2 CLKA's wide, and is synchron- 
ously driven from the rising edge of CLKA. Hardware 
error detection occurs during CLKA low. 

PS Reset Group 

PSR (Peripheral Subsystem Reset, Output, high asserted) 

PSR is asserted by the IP under microprogram control. 
When asserted, the peripheral subsystem should be 
reset. In a debug type of control, it may be desir- 
able to use this pin to set a status bit in an 
external register or possibly cause a special inter- 
rupt. This pin is normally asserted by the IP when 
the peripheral subsystem is believed to be faulty and 
would not respond to other means of control. 

This signal is put out synchronously with the rising 
edge of CLKA. Hardware error detection sampling 
access during CLKA low time. 



Table 3. 43203 Electrical Characteristics 

Table 4. 43203 D. C. Characteristics 

Table 5. 43203 A. C. Characteristics 

Figure 5. Timing Diagram for ACD Parameters 

Figure 6. Timing Diagram for Local Processor Bus Timing 

Figure 7. Timing Diagram for Multibus Interface Timing 

Software Programmable Interface Timing 

To accommodate a wide variety of PS interfaces, there are 
two programmable IP timing parameters: XACK-delay and write 
sample delay. These parameters are located in a data 
structure in iAPX 432 system memory that is accessible to 
the IP via the function request facility. 

XACK-delay is a two-bit quantity that specifies the minimum 
delay before XACK/ is signalled on a transfer. The minimum 
delay can only be attained with buffered accesses. Figure 
XT displays the representation of the XACK-delay codes. 

Table 6. XACK/ Timing Parameters 
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43203 Electrical Characteristics 



Absolute Maximum Ratings 

Ambient Temperature Under Bias Oo C to 70° C 

Storage Temperature -65o c to +150° C 

Voltage on Any Pin with respect to GND -1 V to +7 V 
Power Dissipation 2.5 Watts 
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iAPX 43203 D.C. CHARACTERISTICS 
VCC=5V+10% Ta=Ooc to 70OC 

DESCRIPTION MIN MM DnTTS 



Vile 


Clock Input Low Voltage 


-0.3 


+0.5 


V 


Vihc 


Clock Input High Voltage 


3.5 


VCC+0.5 


V 


Vil 


Input Low Voltage 


-0.3 


0.8 


V 


Vih 


Input High Voltage 


2 


VCC+0.5 


V 


Ice 


Power Supply Current 




450 


mA 


in 


Input Leakage Current 




+10 


uA 


lo 


Output Leakage Current 




+10 


uA 


lol 


@0.45 Vol 










HERR/ 




8 


mA 




FATAL/ 




4 


mA 




AD15...AD0 




4 


mA 




OTHER 




2 


mA 


I oh 


@2.4V 




-0.1 


mA 



1APX 43203 A.C. CHARACTERISTICS 
VCC = 5 + 10% Ta = Ooc to 70OC 



Loading: AD15...AD0 20 to lOOpf 
OTHER 20 to 70pf 



SYMBOL DESCRIPTION 



8 MHz. 
MIN MAX 



5 MHz. 
MIN MAX 



UNIT 



" GLOBAL TIMING REQUIREMENTS 

tcy Clock Cycle Time 125 1000 200 1000 nsec. 

tr,tf Clock Rise and Fall Time - 10 - 10 nsec. 
tl,t2 

t3,t4 Clock Pulse Widths 26 250 45 250 nsec. 

tis Signal to IN IT/ Hold Time 10 - 10 - nsec. 

tie INIT/ Enable Time 8 - 8 - tcy 

SYSTEM SIDE TIMING REQUIREMENTS 

tdc Signal to CLOCK Setup Time 5 - * 5 - nsec. 

ted Clock to Signal Delay Time - 55 - 75 nsec. 

tdh Clock to Signal Hold Time 25 - 35 - nsec. 

tsi Signal to INIT/ Setup Time 15 - 25 - nsec. 

PERIPHERAL SUBSYSTEM SIDE TIMING REQUIREMENTS 
tas AD15...AD0,CS/,WR/,BHEN/ 

Setup Time to ALE Low 
tah A015 . . .AD0,CS/ ,WR/ ,BHEN/ 

Hold Time to ALE Low 
tss SYNC High Setup Time to 

CLKA High 
tsh SYNC Low Hold Time to 

CLKA High 
tsw SYNC High Pulse Width 
tds Write Data Setup to 

Sampling CLKA High 
tdh Write Data Hold to Sampling 

CLKA Low (Advanced XACK/) 
tdhx Write Data Hold to XACK/ 
tasy AD15...AD0,CS/,WR/,BHEN/ 

tsdh CLKA High to HLD,INT,PSR 



0 




0 




nsec. 


32 




35 




nsec. 


50 




60 




nsec. 


30 




40 




nsec. 


50 


2 tcy 


60 


2 tcy 


nsec. 


10 




20 




nsec. 


10 




20 




nsec. 


5 




5 




nsec. 


i.C\J 




lOU 




nsec. 




75 




90 


nsec. 



SYMBOL DESCRIPTION 

8 MHz. 5 MHz. 







MIN 


MAX 


MIN 


MAX 


1 I»l T *T 

UNIT 




PERIPHERAL SUBSYSTEM TIMING RESPONSES 










tsdh 


CLKA High to HLD,INT,PSR 


*• 


75 




90 


nsec. 


ta1h 


Vand AD15 . . .ADOjCS/ 














to Chip INHl Vand Delay 




80 




85 


nsec. 


tede 


OE to DEN/ Delay 




65 




70 


nsec. 


tead 


OE to Enable AD15...AD0 Buffers 














Delay (Read Cycle) 




70 




75 


nsec. 


tdad 


OE to Disable AD15...AD0 Buffers 














Delay (Read Cycle) 


— 


52 




55 


nsec. 


tdsx 


AD15...AD0 Read Data Valid 














Setup to XACK/ Active 














(Non- advanced XACK/) 


20 




20 




nsec. 


teed 


CLKA High to Enable AD15...AD0 














Buffers Delay 




70 




75 


nsec. 


tcvd 


CLKA High to Valid Read Data Delay 


- 


80 




90 


nsec. 


tox 


OE Inactive to XACK/ 














Inactive Delay 


- 


80 




90 


nsec. 


tdds 


AD15...A00 Disable Setup 














to DEN/ High 


0 




0 




nsec. 


txde 


XACK/ Low to DEN/ High 














(Write Cycle) 




35 




A rt 

40 


nsec. 


tcde 


CLKA High to DEN/ Low 




70 




75 


nsec. 




XACK/ TIMING CHARACTERISTICS 














Buffered Accesses with XD=0 












tax 


ALE High to XACK/ Valid 


0 


65 


0 


70 


nsec. 


tdsx 


AD15...AD0 Read Data Valid 














Setup to XACK/ Valid 














(When internal state does not 














allow XACK/ before SYNC) 


20 




20 




nsec. 


tadx 


Valid AD15...AD0 to XACK/ Valid 














(when internal state allows 














XACK/ before SYNC) 




120 




140 


nsec. 




Buffered Accesses (With 














XD=1 or XD=2) or Random Accesses 












tdsx 


AD15...AD0 Read Data Valid 














Setup to XACK/ 


20 




20 




nsec. 




Faulted Accesses 












tsdl 


CLKA Low to NAK/ 




75 




90 


nsec. 


tsnx 


Setup of NAK/ to XACK/ 


50 




50 




nsec. 



Note: All timing parameters are measured at the 1.5 Volt level except for CLKA 
and CLKB which are measured at the 1.8 Volt level. 
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Inhibit WR/ XDi XOq XACK/ Fonnation 

Mode 

0X00 Advanced Acknowledge 

(XACK/ can occur before SYNC) 

0 1 0 '1 Rising edge of SYNC 

0 0 0 1 Rising edge of SYNC plus 1 Clock 

0 110 Rising edge of SYNC plus 1 Clock 

0 0 10 Rising edge of SYNC plus 2 Clocks 

1 XI 0 Rising edge of SYNC plus 2 Clocks 
1 X 0 1 Rising edge of SYNC plus 2 Clocks 
X X 1 1 Illegal condition 



Note: X=don't care condition 

lA%Lt 6. c.-j.^Y.^„Y.x _ XACK/ Timing Parameters 



Write sample delay is a one-bit quantity that specifies the 
position of the internal write data sampling pulse with 
respect to the SYNC pulse. If WSD=0, write data is sampled 
one clock period after SYNC is asserted. If WSD=1, write 
data is sampled two clock periods after SYNC is asserted. 

When initialized, the IP operates with the slowest interface 
timing {XD=10B, Write Sample Delay = IB) . 

Hardware Prograimsable Interface Timing 

In addiion to the software programmable interface timing, 
the design of hardware external to the IP may control the 
delay in formation of XACK/. 

Noting that the rising edge of ALE sets the XACK/ enable 
flip-flop, ALE (style 2 in Figure 8.) may be used to 
postpone the generation of XACK/. The falling edge of ALE 
in both styles latches AD^s-ADof CS/, WR/, and BHEN/. 

Figure 8. Two Styles of ALE 
Buffered Accesses 

Window 0 has the special ability to be used in buffered 
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access mode. High speed data tansfers to or from sequent^ ' 
locations in an iAPX 432 data segment are expedited by the 
IP through the use of an eight-double-byte (16-byte) FIFO. 
When an attached processor acquires data from an iAPX 432 
data segment, the IP prefetches data from iAPX 432 memory. 
When an attached processor transfers data to an iAPX 432 
system, the IP aggregates data in the FIFO before it 
postwrites into iAPX 432 system memory. Transfers into or 
out of the iAPX 432 system are performed in the largest size 
data packet as possible. The IP has the capability to form 
8-, 6-, 4-, 2- and 1-byte transfer requests. An IP will 
transfer smaller sized packets when necessary to complete a 
transfer that is not an even multiple of 8 bytes in length. 

Since data transferred on a processor Packet bus must always 
be right-justified, an IP performs byte packing or unpacking 
when data is moved. Read data from the iAPX 432 memory is 
acquired in 8-byte packets. The attached processor may use 
an 8- or 16-bit bus interface to the IP. Tables 7 and 8 
display the FIFO action for transfers of data from an 
attached processor to iAPX 432 memory via the IP. 

Table 7. 8-bit Processor Interface 

Table 8. 16-bit Processor Interface 
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BHEN/ AO AD7..AD0 Time 

1 0 Byte 6 6 

1 1 Byte 5 5 

1 0 Byte 4 4 

1 1 Byte 3 3 AP Bus 

1 0 Byte 2 2 Transfers 

1 1 Byte 1 1 

1 0 Byte 0 0 
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The 43203 presents an additional challenge in the area of 
hardware error detection, since two separate processor 
interfaces are supported: the iAPX 432 system and the 
peripheral subsystem. 

When INIT/ is asserted, the FATAL/ and HERR/ pins of the 
43203 are examined to establish the mode that each interface 
is to enter. 

Representation of MASTER/CHECKER mode at initialization 



FATAL/ HERR/ iAPX 432 Side Peripheral Subsystem Side 

0 0 MASTER MASTER 

0 1 MASTER CHECKER 

1 0 CHECKER MASTER 
1 1 CHECKER CHECKER 

Logic external to the 43203 must provide these signals. 



Peripheral Subsystem Interface Timing 

iAPX 432 systems are synchronous digital systems. The 
peripheral subsystem (s) employed with an iAPX 432 system 
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need not share the common (CLKA, CLKB) time base* Rather, 
the PS may operate at an independent frequency, allowing the 
system designer to tailor the cost/performance ratio of the 
PS to product needs. 

The asynchronism of the PS to the iAPX 432 is resolved by 
the IP signal SYNC. A synchronizer external to the IP is 
used to generate SYNC, allowing many forms of peripheral 
subsystem to be attached. Two examples of interfaces to 
standard Intel peripheral subsystems are described in this 
section (Refer to Figures 10. and 11): 

Interfacing 8086 Component Bus to the IP 

Interfacing the Multibus to the IP 

Timing calculations are included to show interface design 
and performance. 

Interfacing the 8086 Component Bus to the IP 

The following diagrams and calculations illustrate the 
design considerations in interfacing the 8086 component bus 
to the IP. Timing calculations are shown for both read and 
write accesses. The read access example assumes that the IP 
is operating in buffered mode and the buffer contains the 
required data. The calculations shown allow 8086 operation 
without wait states. 
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Table 9. 
Maximum Mode 8086 System 
8086 Write Data Setup Performance = -tcclh + tclcl + tcldv 
-15 + 250 + 110 = 345 ns; 4 MHz. 8086 
-15 + 200 + 110 = 295 nsj 5 MHz. 8086 

43203 Write Data Setup Requirements = tss + 2tcy + O.Stcy 
tds 

8 + 2(200) + 0.5(200) + 20 = 528 ns; 5 MHz. 43203 
8 + 2(125) + 0.5(125) + 10 = 331 ns; 8 MHz. 43203 

8086 Write Data Hold Performance 

= -tcllh + 3tclcl + tclch + tchdx 
-15 + 3(250) + 151 + 10 = 896 ns; 4 MHz. 8086 
-15 + 3(200) + 118 + 10 = 713 ns; 5 MHz. 8086 
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43203 Write Data Hold Requirements = -tss + 4tcy + tdh 



-8 + 4(200) + 20 = 812 ns; 5 MHz. 43203 



-8 + 4(125) + 10 = 502 ns; 8 MHz. 43203 



8086 Read Data Setup Requirements = 3tclcl - tcllh - tdvcl 



3(250) - 15 - 30 = 705 ns; 4 MHz 8086 
3(200) - 15 - 30 = 555 ns; 5 MHz 8086 



43203 Read Data Setup Performance 



= tss + 2tcy + tsd + 0.5tcy + tcvd 



8 + 2(200) + 8 + 0.5(200) + 90 = 516 ns; 5 MHz, 43203 



8 + 2(125) + 8 + 0.5(125) + 80 = 331 ns; 8 MHz. 43203 



Multibus Interfacing 



Table 10 demonstrates the interface of an IP to an Intel 



135 



Multibus peripheral subsystem. Calculations are included 
for minimum Multibus access time. 

Table 10. Multibus Interface to the IP Calculations 
Table 11. IP/GDP Operator Comparison Table 



136 



3M BRAND 64 LEAD QUIP SYSTEM 



3362-OOCO QUIP 3URN-IN/TEST SOCKET 




Leadless Carrier 
Connector Body 



Convenient ZIF 
Socket 

Rapid interconnection to cir- 
cuitry is accomplished with a 
compact 64 lead zero-inser- 
tion-force connector. Gold 
tipped wiping leaf contacts 
Insure a clean, gas tight inter- 
face with the ceramic carrier. 
The connector insulating ma- 
teria! is the same durable 
glass-filled thermoplastic prov- 
en in our "Scotchflex" prod- 



uct fine and is flammability 
rated at 94 V-0. Solder pins 
are located on standard .100" 
centers making it compatible 
vyith existing printed circuit 
board design guidelines and 
standard assembly equipment. 
A "snap-in" heat dissipating 
cover holds the chip carrier 
in place. An ordinary screw- 
driver permits quick removal. 
See figure 1 . 



TYPICAL PROPERTIES 



Complete- Burn-in 
Capability 

The 3M QUIP System in- 
cludes burn-in connector. 
This connector facilitates high 
volume production testing at 
a minimum cost The durable 
contacts and body ensure re- 
liable testing up to 200°C. 
The heat dissipating cover 
features a positive locking 
quick release latch. See fig- 
ure 2. 



PHYSICAL 


Ceramic: 94% Ala O3— Black | 
Metallization: Gold (60m in. minO over nickei and refractory. ; 

Qsver copper alloy. 

Body: glass filled polyester. . j 
Contacts: copper alloy 725 witfi .000030* gold over nickel 
interface. 

Latch: stainless steel. 
Cover copper alloy. 

Contacts: gold plated (.00001 0 in.) BeNi. 
Scdy: polypnenyiene sulfide (Ryton R4) 


CERAMIC PACKAGE 

3M PART NO. 3534 SOCKET 

3M PART NO. 3382 SOCKET (BURNHN) 


THERMAL 


50*C/watt maximum thermal resistance 


64 LEAD QUIP SYSTEM Bj^: 


ELECTRICAL 


Maximum resistance: .SOOn. 

Maximum interlead capacitance: 5 pfd. 

Dielectric withstanding voltage: 1 000 volts at sea level. 

Current rating: 1 amp. per lead, limited to 30*^0 rise per 

lead. 


64 LEAD QUIP SYSTEM 


ENVIRONMENTAL 




64 LEAD QUIP SYSTEM 

3M PART NO. 3362 SOCKET (BURN-IN^ 


Temperature rating: -55*'C to 105°C. 
Temperature rating: -55*'C to 200*^0. 



'Ryten is a rsQistarvd trademark of PhUUes Chamaeai Co. 

Electronic Products Division/3M 

3M CENTER • SAINT PAUL. MINNESOTA 53 IQI 
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3M Brand 64 Lead Quip System 
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A Complete Quip System From 
The Source 



The 3M Brand Quad-ln-Line 
package system brings built- 
in simplicity and lower total 
costs to microprocessor pack- 
aging. Its smaller size and 
low-profile cut package area 
by one-third, allowing for 
greater board density than 
with conventional 64 lead 
dual-in-line configurations. 
Shorter trace lengths result 
In lower lead resistance and 



capacitance. Faster switching 
times and improved system 
performance can be achieved. 
A carrier to connector polar- 
izing feature eliminates costly 
assembly errors. 
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Reliable Ceramic 
Package 

The heart of the 3M QUIP 
System is a reliable, co-fired 
multilayer leadless package. 
Its design permits easy re- 
placement and field repair. 
Costly brazing and metallized 
leads are eliminated. The 
rugged, optically opaque cer- 
amic structure is chemically 
inert, dimensionally stable 
and thermally conductive. A 
low thermal resistance makes 
possible the use of IC's with , 
greater power requirements|^ 
increasing overall circuit per-' 
formance. 



LEADLESS QUAD IN-LINE 
CERAMIC PACKAGE 




X ^ NOTES: ^ * 

SCOPE: THIS SPECIFICATION DETAILS THE REQUIREMENTS FOR A MULTIPOSITION 
LEAOLESS CERAMIC PACKAGE SOCKET 



PIN#1 



SPECIFICATIONS - 

PHYSICAL ; INSULATOR MATERIAL 

CONTACT BASE METAL 
CONTACT INTERFACE 



GLASS REINFORCED GRAY THERMO 
PLASTIC U.L. FLAMMABILITY RATING 94V-0 
COPPER-NICKEL-TIN ALLOY 725 
0.000030" (.762 urn) MIN. GOLD OVER 
0.000050" (1.27 urn) MIN. NICKEL 



ENVIRONiytEiyTAL; 

TEMPERATURE RATING- -670F to +2210F 
( SSOC to I^IO&OC) 



•31 SPACES @ .Q50/(1.27) EA. 



♦ ^ f f t- 

• ♦ ♦ f + - 



♦ t-t^t'^T- 



.Q^O^ .08 

"(1 .27) f (1.64) 
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(7.62) 
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J 

I 

I — f t 4^ 4^ 4 — 
— f f ♦ t f ♦ - 



-PIN#1 





.040 
(0.79) 



DIA. 



CONNECTOR DETAIL 



HOLE PATTERN DETAIL 



USED ON 
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ELECTRONIC rnOIMJCTS 

St. Paul 
Minnesota 


ISSUE 


ISSUE DATE AND 
CHANGE RECORD 


REV. 


CH. 


3534 QUIP SOCKET 
SPF.CIFICATION 

64 LEADS 


TOLERANCE UNLESS NOTED 


INCH 
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(mm) 


SCALE 
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SK-77-073 
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APP, 



NOTES: 

1. ) CERAMIC MAT'Li AISi Mag 777 (04% AlaOs - fiLACKt. ' *^ ' 

2. ) METALLIZATION: REFRACTORY METAL * NICKEL * GOLD (60u" MIN.). 

3. ) PACKAGE SUPPLIED TO 3M SPEC. NO. S 90-007. 

4. ) MAXIMUM LEAD RESISTANCE .SOOA. 

&.) MINIMUM WIRE BOND PAD SIZE IS .025 LONG X .010 WIDE. 

6.) DIE PAD, SEAL RING, AND NO. 1 LEAD ARE ELECTRICALLY ISOLATED. 
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